>Что вам мешает найти тот, который подойдет именно вам?
так в том и проблема этих видео курсов - 99% полная ерунда. Не имея знаний, найти толковый курс практически невозможно. А имея знания, курс уже не нужен.
Время, потраченное на поиск курса можно более продуктивно потратить на изучение темы.
lloydbanks, ха
>ормальный верстальщик не будет оставлять в своем коде дерьмо в виде
так вот для этого валидатор и нужен - чтоб не просматривать вручную весь код на наличие незакрытых тэгов/ошибок верстки, а проверить это автоматизированно.
>80% скуления и нытья валидатора - это кастомные атрибуты и невалидные метаданные
еще раз ха
ну вот тебе корпоративный сайт, где точно так же относятся к валидаторам. https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww...
Дубликат ID (#collapseMain) - это уже серьезный баг, если к айдишке привязан скрипт, может много непонятного происходить у клиента
>Думаете они не могут себе позволить хорошего фронтенд-разработчика? Конечно могут
конечно могут. Но. Ты работал с корпоративными клиентами? Где куча легаси кода, большие команды работают над продуктом, одна команда не знает, что делает другая, и вот это вот все?
удалять все ошибки из валидатора не нужно. Но это не значит, что пользоваться им нет смысла.
Ну и моя мысль немного не о том. Учиться лучше по тому коду, где вообще нет ошибок. Когда уже есть опыт, тогда можешь понять, какие ошибки критичны, а чем можно пренебречь
>На что действительно стоит обращать внимание - это на показатели Google PageSpeed
еще раз ха
GPS хороший инструмент. Но точно так же, нужно уметь им пользоваться и подгонять сайт под 100 гугловских попугаев не всегда оправданно. Например вот https://www.facebook.com/notes/wordpress-speed-up/...
>просто основываясь на своем 8 летнем опыте разработчика (в основном бэкенд
>А на сколько он у вас валидный
на бэке код можно писать по стандартам. а можно не по стандартам при том, и тот и тот, будут работать одинаково производительно.
какой код будет проще и дешевле поддерживать?
а если, например, разработкой кода до этого занималась команда индусов? или, наоборот, теперь код передадут команде индусов, но нужно оставить такое же качество кода. Может все же стоит озаботится валидностью кода?
lloydbanks, я считаю, что хороший верстальщик должен уметь верстать под разные экраны, валидно, уметь использовать микроразметку и чтоб это грузилось быстро. Большие корпоративные сайты на это часто забивают.
Валидатор позволяет очень быстро оценить уровень верстки. В реальной жизни не всегда оправданно делать 100% валидный сайт, но автору вопроса посмотреть на ошибки в его верстке, почитать что они значат, сильно бы помогло https://validator.w3.org/nu/?doc=http%3A%2F%2Fm977...
добавлю
в больших проектах стоит смотреть, как оно все устроено изнутри: как оно собирается, как сделан ci, какая структура файлов, как идут тесты и всякое такое. Но внутрь никто не пустит, а со стороны фронта там может бы много странного и не очевидного.
elo-dev конкретно по этой верстке:
почитать по srcset, научится грузить картинки правильных пропорций, почитать про сборку проектов (grunt, webpack, etc), почитать про БЭМ
$num=-1;
нельзя, нужно какой-то лимит, хотя бы 300-400. Иначе на большем к-ве постов упадет
$slug='Ограждения из нержавеющей стали';
такой слаг не может быть
'mytypes'=>$slug
mytypes - такого параметра нет, поэтому слаг никак не передается в Query
попробуйте начать с чтения документации?
там довольно подробно это расписано
NeganL,
>Думаете, такой человек будет в веб особо нужен?) Он будет новичком, а новички никому не нужны.
Вот именно. Новички нигде не нужны и на первом этапе зарплата в среднем везде маленькая.
Но через год-два жизнь ведь не закончится? Отработает он 1Сником, наберется опытом, на что он сможет претендовать? На все тот же круг вакансий оффлайн в городе?
А скоро пенсия, предпенсионеры никому не нужны. Через пяток лет заменят его на более молодого, что, опять тогда переучиваться? Удаленно же возраст не спрашивают.
На мой взгляд, у удаленной работы плюсов больше. Но автору и этот вариант не поможет. Судя по постановке вопроса, сам решать не умеет, не умеет расставлять приоритеты, анализировать - добиться чего-то на любой работе уже не сможет. Для примера, друг задался таким де вопросом будучи младше автора вопроса на несколько лет: поменял жизнь, отучился на пилота, сейчас летает.
1 идя работать в 1С автоматом привязываете себя к городу, в котором живете. И, что хуже, к зарплатам, которые есть в этом городе. На удаленку вакансии по 1С очень редки.
идя работать в вэб, перед вами весь СНГ - удаленно можете работать в любой компании. А если знаете английский, то вообще практически в любой точке планеты. Другой вопрос, что и конкурентов у вас будет больше, и удаленное трудоустройство/работа несколько специфичны.
учитывая, что год вы хотите потратить на обучение и сколько-то еще займет поиск вакансии, подумайте, кому в городе нужен будет дядька под 40 на вакансию джуниора в 1С? и готовы ли вы будете работать на такой вакансии?
2 спрашивать тут, куда идти, идея ваще плохая. Каждый будет советовать то, что он видит и считает более выгодным. И не факт, что эти мнения будут для вас правильными.
Лучше просмотрите вакансии за год в вашем городе, просмотрите вакансии на удаленку. Отсортируйте по зарплатам. Посмотрите требования. Прикиньте, что сможете из этого выучить быстрее (для этого можно тупо взять несколько сайтов с курсами, сравнить длительность обучения по разным специализациям у их курсов- точное время вам это не даст, но примерно нужный объем знаний прикинуть получится).
Если вам стоит вопрос зарабатывания денег, а не приятного проведения времени, то какая разница чем заниматься? Приоритет - деньги/скорость вкатывания/наличие вакансий. Вот по такому соотношению и ищите.
>А это тут каким боком?
таким, что они занимаются продажей плагинов для сеток сайтов на WP. У них бизнес именно на этих сетях заточен. Раз они столько лет над этим успешно работают, считаю, в WP они разбираются.
>Разве мы говорим о корпоративных сайтах и интернет-приложениях
при чем тут корпоративные сайты и приложения? эти чуваки делают плагины для мультисайтов на WP.
если сложно понять, могу как-то по другому написать
>1 мультисайт с 10 субдоменами повлияет больше чем 10 отдельных вордпрессов
видимо вы как-то не так читаете. В статье идет сравнение между разворачиванием мультисайта на поддоменах и разворачивании мультисайта с папками. А не сравнение мультисайта с несколькими отдельными инсталлами.
у них бизнес с этими мультисайтами связан. не будет он писать, что мультисайт - в некоторых случаях плох. но сравнить разные варианты разворачивания именно мультисайта они себе позволить могут. что в той статье и описано.
>отнимает больше времени на управление(хотя это не правда
да ну? значительно проще и удобнее использовать сервисы вроде https://infinitewp.com/
так у нас остается отдельный инсталл, но управлять всеми ими можем массово.
и люди, почему-то, за такой вариант голосуют деньгами - используют именно такие платные сервисы для управления отдельными инсталлами, вместо установки бесплатного мультисайта. Вот они глупые, да?
>чем однин мультисайт с одним набором плагинов!
в реальной жизни чаще нужен разный набор плагинов для разных сайтов внутри сетки.
>нельзя один сайт перенести в другую БД
а вы пробовали? перенести, конечно, можно. Но это не совсем тривиальная задача. Сравнивая с переносом отдельного инстала, выгрузил дамп-поменял пути-загрузил дамп, не пойдет. например вот, небольшая инструкция https://pressjitsu.com/blog/moving-single-site-wor...
>он был уже адекватен в 2005м, а счас уже 2020 на носу
ок, с годом я действительно ошибся
ну раз моему мнению не верите, почитайте, что пишут чуваки, которые на сетках сайтов в промышленных масштабах деньги делают (кстати, разговаривал с их CTO на wceu этим летом - умный дядька, фигни не скажет) https://premium.wpmudev.org/blog/wordpress-multisi...
там, правда, больше об отличии субдоменов и папок, но, поверьте, в сравнении с чистым WP сетка все эти проблемы так же сохраняет. Плюсом добавляется, что не все плагины умеют работать с сетками, не все хостинги поддерживают (да, есть и такие), значительно больше времени уходит на поддержку и тп.
>За последние лет 15 не наблюдаю особых проблем!
а ничего, что WP всего 12 лет? ну и более-менее массово он стал примерно с 3й версии (это всего ~10 лет назад) использоваться? или у вас что-то свое, воображаемое?
а я бы так сделал
SELECT DISTINCT YEAR(post_date) FROM wp_posts WHERE post_status = 'publish' ORDER BY `YEAR(post_date)` ASC
потому как дистинкт иногда может быть быстрее https://stackoverflow.com/questions/581521/whats-f...
"То есть цели мои какие - не тащить каждый раз ядро ВП внутрь папки с проектом (а таких проектов будет много), второе это отслеживать гитом изменения только в wp-config.php и wp-content, третье это работать только под одним доменом"
плохая идея. "работать только под одним доменом" можно реализовать без таких костылей.
но, если хочется, посмотрите вот тут https://github.com/roots/bedrock/tree/master/web
"‘C:\gulp\" - это и не сработает
вам нужно указывать пути относительно вашего сервера. А он про диск C и прочее такое ваще не в курсе
в документации написано, нужно использовать хук wp_enqueue_scripts
идем дальше
какой параметр нужно передать вторым в функцию wp_register_script?