• Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca, хм.. если речь идет о сайте / проекте целиком, то у меня композер в корне, все зависимости - они на то и зависимости. Это и либы, и плагины/mu-плагины, и сама тема. Все это подключается из корня и управляется одним composer update. В чем разница между каким-то сторонним плагином / либой (типа CarbonFields например) и своим кастомным решением для CPT/CT? Ни в чем, и то и другое - код, без которого сайт не будет работать.

    Ну, у меня как раз со скоростью ядра проблем нет) Работает вполне себе хорошо и даже быстро. Что могу сказать наверняка - не медленне, чем Laravel. А вот сторонний код чаще всего оставляет желать лучшего.

    С ларой по сути та же проблема. Низкий порог входа и все легко и красиво. Как результат - медленно. Не вытеснит ларка вордпресс :) Не вытеснит.
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca, ну, это уже личные предпочтения. Я вот озабочен performance по самое немогу, поэтому без dump-autoload как бы не работаю по определению. В принципе я и не вижу в этом проблем - на локальной машине дампить автозагрузчик нет необходимости, пусть себе хватает все на лету, динамически. А при деплое на прод в пост-деплое дергайте дампинг и все. Локально - удобно работать. На проде - быстро. И все автоматизировано.
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    thehighhomie, а вот это не ко мне, сорян :) Я с frontend завязал 2 года назад)) и ни разу не пожалел)) моя стихия - backend.
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca, я не совсем понял в чем смысл "без обновления Композера" и по поводу изменений на лету.
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca,
    в Sage он вроде уже есть. Я про автолоадинг.

    Кстати да. Он же ставится через Composer.
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca,

    скорость я думаю таки на стороне файлов, нежели базы, в нашем случае.

    Нет, потому что метаданные и так тянутся, по определению. Праймится post cache. Метаданные будут читаться в любом случае, дополнительных запросов нет. Одно дополнительное поле в результатах запроса, который и так будет выполнен, совершенно никак не скажется на скорости. Выборка идет по индексу post_id.

    Чтение тонны метаданных из замечательно спроектированной базы Wp ну никак не сможет обогнать одну проверку пыхи на наличие файла. Можно поспорить, если есть желание.

    А что тут спорить? Если бы нужно было делать отдельный запрос в БД - тогда да, можно бы какой-то benchmark запилить и проверить. Но отдельного запроса нет, мы просто подбрасываем еще одну строчку в результат уже существующего запроса. Overhead практически равен 0. При использовании object cache - реально 0.

    thehighhomie,

    и при удалении/редактировании страницы нужно удалять/редактировать ассеты.

    В предложенном мною варианте сами файлы asset'ов конечно тоже не помешает удалить из файловой системы и проекта. Но самый важный бенефит - при удалении страницы удаляются и ее метаданные, а значит эти ассеты уже не будут грузиться, система забывает об их существовании. Кроме того, на удаление страницы можно повесить функцию, которая эти ассеты удалит сама, или хотя бы запишет в какой-то лог, что их надо удалить как неактуальные. При следующей сборке ассетов этот лог даже можно использовать на лету для предотвращения генерации этих assets.

    а на счет namespaces и autoloading в вордпресс можно подробней? пример с каким нибудь модулем или приложением? пожалуйста

    Гуглите wordpress + namespaces + autoloading. Там просто вариантов конфигурации больше чем один. Можно свой автозагрузчик, можно Composer на уровне плагина (или темы), можно Composer глобально на уровне сайта целиком (я предпочитаю такой метод).
  • Wordpress: грамотное подключение скриптов и стилей для разных страниц?

    zorca,
    Мы разбиваем functions.php на отдельные файлы с аатозагрузкой из нужной папки, чтобы не путаться.

    У меня в functions.php только after_setup_theme, все остальное автолоад. Это как бы само собой разумеется. У тех, кто еще не добрался до namespaces и autoloading, но уже более-менее продвинулся, будут require_once модульных файлов из какой-нибудь папочки inc.

    Метабокс избыточно

    Чем избыточно?

    можно проверять на наличие файла css со слагом страницы

    То есть lookup file_exists? Имхо, взять из памяти готовые, уже загруженные метаданные - быстрее.

    Но суть даже не в скорости. Слаг может поменяться. Если сайт клиентский он не просто может, он гарантированно поменяется. Через какое-то время страницу переименовывают - в угоду SEO или по другим причинам - не важно. Через год таких переименованных страниц - масса. И у вас каша. Вы ни сном ни духом, где такая загрузка по слагу сломана, а где нет - ваше решение даже не тестируемо. Любое изменение требует модификации кода, что не есть разумно с точки зрения поддержки.
  • Как преобразовать $_POST в массив php?

    А что у вас в $_POST['meters']? Покажите состояние массива $_POST при отправке формы.
  • Какая OC легче воспринимает нагрузки?

    sim3x,
    Прод для веб на PHP под Windows? Я надеюсь это шутка?
    Разумеется, "пофиг какая ось" = любая линукс/юникс ось.
  • Какая OC легче воспринимает нагрузки?

    sim3x,
    Беру сервер для сайта, PHP скрипты есть

    Windows? Really?
  • Какая OC легче воспринимает нагрузки?

    Анроид, например, или freeNAS?

    Вы снова шутите? Или хвастаетесь знанием всех мыслимых и немыслимых осей на этой планете? Мы говорим о распространенных серверных ОСях общего плана, какой в пятую точку адроид? Какой FreeNAS? Еще макось добавьте. ТС четко спросил по поводу оси для веб и PHP.

    Давайте так "разумеется" нужно уточнять конкретнее, потому что оно совершенно неочевидно.

    Ничего личного, но тут явно неочевидно конкретно вам. Видимо сам вопрос почитать забыли. Подозреваю, в силу вродженной или приобретенной вредности. Комментариев по сути нет, одни нелепые попытки сострить.

    Также для корректности стоит уточнить, что абсолютная доля Apache не так уж и снижается, и все еще заметно выше 60%, а доля nginx растет не столько из-за него самого, сколько из-за него самого, а из-за того, что многие платформы умеют сами в веб-сервер (всякие веб-сайты на питоне, go, nodejs, не забываем и про microsoft и про tomcat). В то время, как nginx все еще часто ставят перед ними для балансировки и отдачи статики.

    Давайте по сути. Приносите цифры, тогда будем говорить. А пока что я вижу вот это:

    5a797db66839a355069943.jpegПодробнее у NetCraft. Можете полистать архивы в обратном порядке. Там очень много полезной информации.

    Nginx часто ставят как прокси. Точно так же часто HAproxy ставят перед Nginx. Это не имеет значения. Вы говорите сначала об абсолютных цифрах Apache, а потом скатываетеьс в нюансы Nginx. Сильно смахивает на попытку манипуляции. И самое главное - вы ведь не опровергаете мои утверждения, а только говорите "не все так однозначно". К чему это?

    Microsoft не обсуждаем вообще. Он весьма и весьма силен в своей сфере, но мы говорим о стандартном сервачке с PHP и парочкой сайтиков. Это разные вселенные, и они не пересекаются.
  • Куда ехать фрилансить, в какую страну?

    Никита, Вы там в Европе жили или нет? Ваши рассуждения - это догадки и экстраполяция или реальный опыт? Я жил. Польша, Черногория, Германия, UK, Испания, Болгария. И Турция в придачу. Есть с чем сравнить и подтвердить.
  • Какая OC легче воспринимает нагрузки?

    Saboteur,
    Особенно под win nginx особенно хорошо работает, правда?

    sim3x,
    Nginx не так хорошо работает на виндовсе

    Прод для веб на PHP под Windows? Я надеюсь это шутка?
    Разумеется, "пофиг какая ось" = любая линукс/юникс ось.

    SyavaSyava,
    Обожаю такие ответы...
    Видимо всем админам серверов на Apache, доля рынка которого в 2 раза больше, чем у nginx, нужно срочно обратиться к вам за консультацией, на что им следует плевать.

    Для начала, я как раз из тех админов, которые начинали с Apache в девяностых, когда Nginx еще и не существовал, а Сысоев еще и не догадывался, что когда-то его запилит.

    Главные причины популярности Apache - его возраст (и, соответственно, распространенность во все уголки планеты, ибо были времена когда по сути это был единственный веб-сервер, не то что сейчас), и его runtime-гибкость благодаря .htaccess, что делает его незаменимым для shared-хостингов.

    Среди не-shared хостингов и high-load серверов он уже давно уступил позиции альтернативным решениям, лидирующим среди которых является как раз Nginx.

    Главные различия, которые нас интересуют - Nginx существенно быстрее и использует меньше памяти. А значит, если автора вопроса интересует держать нагрузку, то при тех же ресурсах Nginx сможет держать сильно больше, чем Apache. При нормальной конфигурации настолько больше, что какая там ОС действительно значения иметь не будет.

    Пруфы по производительности:

    https://www.rootusers.com/linux-web-server-perform...
    https://help.dreamhost.com/hc/en-us/articles/21594...

    Apache, доля рынка которого в 2 раза больше, чем у nginx,

    Для корректности стоит уточнить, что:
    - доля Apache стабильно снижается уже не один год
    - доля Nginx стабильно растет уже не один год
    - оба тренда имеют еще более резкие очертания в high-load, top 10k, top 100k и top 1kk этих ваших интернетов
  • Как правильно написать или подключить js файл в wordpress?

    N!crO,
    спасибо за помощь)

    На здоровье) Скинул решение отдельным ответом с комментарием, можете отметить.

    слайдер для новичка нормальный?

    Слайды крутит? Значит нормальный :)

    В целом большой респект и плюс в карму за ванильку а не всякие эти jQuery.
  • Как правильно написать или подключить js файл в wordpress?

    N!crO,
    var slides = document.querySelectorAll('.slider-item');
    var sliderToggles = document.querySelectorAll('.slider-toggle');
    var currentSlide = 0;
    
    if ( slides.length > 0 ) {
        var slideInterval = setInterval(nextSlide, 2500);
    }
    
    function nextSlide() {
        sliderToggles[currentSlide].classList.remove('slider-toggle--active');
        slides[currentSlide].classList.remove('active');
        currentSlide = (currentSlide+1)%slides.length;
        sliderToggles[currentSlide].classList.add('slider-toggle--active');
        slides[currentSlide].classList.add('active');
    }
  • Как правильно написать или подключить js файл в wordpress?

    N!crO, ну, это конечно вариант, хотя грубый. Покажите ваш js, так быстрее решим
  • Как правильно написать или подключить js файл в wordpress?

    N!crO, ну так оберните ваше "дальше" в проверку и запускайте только если поиск дива вернул ожидаемый результат, а не undefined. WordPress то тут при чем вообще?
  • Как запретит удаление таксомии?

    Напишите подробнее. Это кастомная или стандартная таксономия? Вы имеете в виду удаление терминов или дерегистрацию самой таксономии?
  • Какой плагин Wordpress поставить на сайт чтобы сделать словарь- вывод материалов по алфавиту?

    kugno, в общем-то, при описанном подходе программист особо и не нужен, здесь все идет через стандартный функционал WP. Ну, разве что автоматизация и индексация существующих записей, но это уже бонусы, все будет работать и без них. Для "не-программиста":

    1. Регистрируете custom taxonomy. Есть онлайн-конструктор, есть плагины для WP, которые позволят сделать это без знания кода.
    2. Создаете термины, точно так же как категории (рубрики).
    3. Назначаете их статьям (точно так же как категории).

    ЧПУ и страницы архивов вы получаете автоматом, об этом WordPress позаботится. Остается:

    - сделать произвольный шаблон для архива исходя из иерархии. Создайте taxonomy-$taxonomy.php, где $taxonomy - название (слаг) вашей таксономии. В моем изначальном примере это letter. Теперь "страницы" всех букв алфавита будут использовать этот шаблон.
    - в этом шаблоне создайте меню с буквами. Можно через меню, можно через виджет, можно вывести термины через код. Это все легко гуглится, либо можете задать отдельным вопросом.
    - все, готово.