campusboy

К сожалению, чтобы Вам что-то посоветовать - необходимо узнать Ваш личный "фундамент". Хоть указанная Вами книга и будет полезной (даже с учетом того, что она писалась для MySQL версии 4.х, фундаментально как в СУБД, так и в SQL и в конкретном синтаксисе MySQL последнее, наверно, десятилетие, ничего не менялось), я бы посоветовал следующий алгоритм обучения:

1) Знакомство с основами реляционной алгебры, нормальными формами и реляционной моделью. Без фанатизма, прочтение и осознание статей даже на Википедии хватит за глаза.

2) Знакомство с спецификацией SQL2008. Опять же, без фанатизма. В любом случае, работать Вы будете впоследствии с определенным диалектом языка.

3) Выбор диалекта языка. Подбор литературы (практически любой, за исключением книг из серии "{0} для чайников" и "100 и одно решение для {0}"). На этом этапе важно определиться также с инструментарием, который Вы будете использовать в дальнейшем. Для начала подойдет любой онлайн интерпретатор SQL кода, к примеру sqlfiddle. Но по мере изучения Вам понадобятся более сложные инструменты.

4) Знакомство с UML. Точнее, если по минимуму, с той частью, которая затрагивает прототипирование БД. SQL и СУБД - это инструменты, которые позволяют автоматизировать процессы бизнес логики. UML позволяет эти процессы описать и на основе этих процессов создать прототип схемы БД, от которого уже можно идти к конкретной реализации.

Итак. Четыре базовых шага выполнены. Дальше все просто, перевариваете информацию и занимаетесь практикой от простого к сложному (в комментариях уже указывали вполне годные наборы задачек). Попутно узнаете особенности программной реализации выбранной Вами СУБД. И внимательно читаете документацию от разработчика. На примере SQLite, у них подробно разобрана семантика запросов: SQLite CREATE. Под MySQL найдете сами.

Теперь поясню, почему все четыре шага важны.
1) Без базовых фундаментальных знаний вы просто не поймете, почему, к примеру, в ячейке столбца номера нельзя указывать два номера телефона, или как работают ограничения на целостность данных.
2) Хоть диалекты SQL и отличаются от стандарта SQL:2008, следует понимать, что знание стандарта позволит Вам в случае необходимости переключиться с одной СУБД на другую. Также, хорошая реляционная SQL СУБД должна быть совместима с этим стандартом априори.
3) Тут на Ваш вкус. Посмотрите изложение автора перед покупкой, посмотрите списки того или иного программного обеспечения. Но факт остается фактом, что прочтение только стандартов, мануалов и официальной документации - путь явно не для всех. Кому-то просто необходимо "художественное" изложение, да и просто из книг можно почерпнуть реальные примеры из опыта автора.
4) Надо понимать, что реляционные СУБД всего лишь инструмент для хранения и обработки данных, обеспечивающий определенные бизнес-процессы определенной предметной области. И под бизнес-процессами следует понимать не как какую-то эфемерную для простого человека вещь, а то, что закладывается под этим словом в оригинальном языке, т.е. совокупность процессов\действий, направленных на создание продукта\предоставление услуги. А средства UML позволяют все это описать в стандартизированной графической форме. Чтобы знать SQL не надо знать UML, не надо знать, что такое и, к примеру, ЖЦ программного продукта. Но со временем, если Вы захотите расти дальше, Вам нужен будет инструмент прототипирования. Также, как если вы дорастете до архитектора БД, вам нужно будет представление о том, как эти БД проектировать, начиная с описания предметной области и заканчивая организационной точкой зрения. Стандарты ГОСТ 34.601-90 и ISO/IEC 12207:2008.

Я, как и многие, начинал с какого-то полу прочитанного учебника и примеров из сети. Сейчас я понимаю, что просто потратил время практически впустую. Как ни странно, хоть и принято ругать наше образование, но список курсов для специальностей "ПИ" подобран не просто так. Помимо самого языка следует знать математический "бэкенд" и как его использовать для реализации задач предметной области. Я отношусь к SQL потребительски, это не мой основной язык, но сейчас я понимаю, что если бы уделил ему больше внимания не как языку, а, в первую очередь, как к одному из инструментов СУБД, работающих на основе реляционной алгебры для обеспечения бизнес-процессов, я бы избежал кучу потерянного времени, костылей и ошибок. Надеюсь, мой ответ будет Вам полезен.

Я перед собеседованием на должность sql-джуна будучи полным нулем за ночь порешал задачки на этом сайте и на следующий день решил все предложенные задачи и был принят) Скажу так - я бы посоветовал порешать эти задачи, они там предлагаются по нарастанию сложности и подкреплены теорией, за которой вам не нужно лишний раз лезть в учебники. Уверяю, с каждым десятком решенных задач Вы будете чувствовать себя гуру sql) Спустя задачек 30, когда у Вас сформируется представление о том, что из себя представляет SQL на деле, тогда можно приступать к литературе, поверьте, после практики гораздо легче воспринимать материал, ибо уже имеется представление, о чем речь.
По литературе(с небольшими пояснениями):

1. Введение в системы баз данных(Автор C.J.Date) - на мой взгляд очень доступное и максимально компактное описание того, на чем базируется SQL, разжеваны основные понятия, рассмотрены нормальные формы, а после предлагаются задачки.

2. SQL Полное руководство - тут понятно по названию, здесь можно найти описание всех возможностей. Ищите наиболее позднее издание(у меня третье, для примера, это 2015 год).

3. Программирование баз данных SQL Типичные ошибки и их устранение - был влюблен в эту книгу за ее легкость и наглядность. Тут вам не просто покажут наглядно, как делать не нужно, а еще и предложат возможные и наиболее эффективные решения для тех или иных ситуаций.

Если вы выбрали MS SQL Server:

1. Microsoft SQL Server 2012 Руководство для начинающих - там хоть и не сильно углубляясь, но описано почти все что нужно на начальных этапах. Там и про индексы, и про оптимизацию, и про бизнес-аналитику, в общем, рекомендую.

2. Microsoft SQL Server 2012 Создание запросов - просто и исчерпывающе(на момент издания) о том, как можно и нужно писать запросы на t-sql(расширение sql для MS SQL Server) с закреплением материала предлагаемыми заданиями.

Если Вы выбрали Postgresql, то официальное руководство там исчерпывающее.

По Oracle и MySQL советов дать не могу, ибо дела не имел. Удачи!

потому что у вас acf сейчас отдает:

yandex.ru

а должен отдавать:

http://yandex.ru

Либо в начале ссылки (перед выводом acf) поставьте двойной слеш вот так:

<a href="//<?php the_field('instagram', 'option'); ?>" target="_blank" class="ico-social"><i class="fab fa-instagram"></i></a>

Дело не в вордпрессе.

VCS -> Local History -> Show History

Используйте Git(или аналог) и таких проблем не будет.

Первая причина в том что LP как одна страница - это понятие изуродованное в РФ.
LP далеко не всегда есть одна страница. Мы делали сайт из 100 LP, структурированные в дерево.

Вторая причина в том что по большей части оптимально начинать с одностраничника (это сайт из одной LP), но кто сказал что на этом стоп? Если бизнес адекватный, то через неделю захочется продолжения банкета. Делать блог, каталог продуктов, или другие LP. Из одностраничника превращаться в каталог смежных продуктов, с кросспродажами и прочим блекджеком.

Третья причина в том что сделать LP на WP можно без излишних затрат. Как уже сказали выше это может быть VC или PageBuilder. Страница собирается за 15-30 минут. Без кривой верстки, кроссбраузерная, адаптивная. По конверсии такие страницы не уступают ручным сборкам (от 2 до 20% легко выжимается), а по затратам в 10 раз меньше.

Четвертая причина. Это решение на много гибче. Проще делать сплит тесты. Поправить блоки местами можно парой кликов или движением мышки. Править может маркетолог без знаний верстки или кодинга.

Ни в коем случае не ставить никаких ISP Manager / Vesta / CPanel, иначе никогда не научитесь тому, чему хотите научиться. Кроме того, они жрут ресурсы. Даже Vesta, которая самая легкая, их жрет прилично, а я сильно сомневаюсь, что у вас VPS c 8+ Gb памяти.

Изучать надо по урокам и статьям, читая мануалы и best practices по каждому package. Порядок, плюс-минус, таков:

- развернули ось
- сделали сразу апдейты
- создали и настроили swap
- поменяли пароль рута на что-нибудь супер-мега-сложное (его мы использовать все равно не будем)
- создали себе обычного юзера с паролем нормальной сложности (он будет использоваться для sudo)
- дали юзеру права sudo
- закрутили гайки по SSH - сменили порт, запретили вход руту и вход по паролю (только по ssh-ключам), разрешили вход только одному своему новому логину
- настроили UFW - простой, но эффективный firewall на основе iptables - default deny, allow http, https, свой кастомный ssh-порт. Если логиниться будете только из нескольких мест (офис, дом) - можно вообще ssh разрешить только на эти IP.
- sudo dpkg-reconfigure tzdata чтобы установить свою временную зону, так логи потом легче читать и понимать
- настроили logrotate
- настроили logwatch
- настроили Postfix, чтобы сервер вам письма мог слать (мы его настраиваем на внешний мейлер, например Mandrill, чтобы все письма точно в спам не падали)
- настроили fail2ban (потом, после установки и настройки веб-сервера и сайтов, в fail2ban можно дополнения писать, например мы на WordPress-сайтах мониторим попытки авторизации в админку и блочим тем же fail2ban)
- дальше ставим все что нужно - Git, Nginx, HHVM, PHP5-FPM, MariaDB, Memcached/Redis и так далее.

Регулярно заходите на сервер, делайте apt-get update && apt-get dist-upgrade.

p.s.: это по ubuntu/debian, для других систем все то же самое, но packages и команды могут немного отличаться

Допустим, я и Вы - оба граждане Российской Федерации. Мы с Вами подписали договор, по которому я Вам плачу условные 5 т.р. за 10 часов Вашей работы в месяц. Все у нас было хорошо 6 месяцев, однако, потом с моей стороны возникли проблемы, скажем клиент/партнер меня кинул, на счете у меня осталось 25 рублей, откуда брать денег не понятно. В данном случае, не получая денег от меня Вы останавливайте работу и имеете право подать на меня в суд с требованием взыскать условныу 5 т.р., которые я Вам задолжал. С Вашей стороны, да и со стороны закона все чисто, гладко и ровно.

Теперь давайте переместимся на мою сторону. Денег у меня на счете сейчас нет и не предвидится. Взять бысто деньг мне не от куда. С Вами по существу мне спорить не о чем. Я прекрасно понимаю, что если Вы получите решение суда и предъявите его приставу, то мой счет будет очень быстро заблокирован и как-то рассчитаться с Вами я не смогу. В таком случае, моей стратегий будет затягивание времени. Скажем, Вы подаете на меня в суд, я в суде заявил возражение, мол истец не выполнил в полной мере процедуру досудебного урегулирования конфликтов, предусмотренную договором. Разумеется, в нашем договоре есть пункт типа "Все споры и претензии решаются путем переговоров...", однако, не прописан их формат, условия согласования и т.п. На этот момент я давлю и прошу отложить рассмотрение дела по существу на 8 недель. Затем, через 2 месяца я предоставлю в суд справку о том, что мол ложусь в стационар на неделю, поэтому присутствовать не могу и т.п.

Всеми этими действиями я добиваюсь одного - максимально отсрочить блокировку моего счета, как план минимум. Мне это нужно для того, чтобы найти способ залатать дыру, которая у меня появилась из-за недобросовестных действий моего клиента/партнера. Для того чтобы Вы не подали на меня в суд вовсе, я могу начать докапываться до всяких мелочей, в духе а вот тут две запятые не в том месте... либо я могу начать пугать Вас, мол по Вашей вине у меня вот сайт упал, я понес убытки, для тебя это такая-то статья ГК РФ... либо я могу развести Вас на какое-то правонарушение, и имея на руках на Вас компромат сказать: "Да, я Вам должен условные 5 т.р.,однако, если Вы подадите на меня в суд, тогда я достану вот эти вот факты и заставлю Вас заплатить условные 10 т.р." Эти дела никак не связаны, однако, в Вашей голове промелькнет: "Да ну его нафиг, не буду с этим му###м связываться", чего мне собственно и нужно.

Отмечу, что это все очень-очень геморно, даже если мы с Вами живем в одном мегаполисе. В Вашем же случае речь идет о разных государствах, что в десятки раз еще проблематичнее.

В Вашем случае, Вы должны вспомнить одно замечательное выражение: "Последнюю работу я делаю бесплатно". Автора, к сожалению, не помню, но суть от этого не меняется. У Вас наступил плохой случай, последний этап работы Вам никто не оплатит. Примите это как факт, запишите этого клиента в свой список недобропорядочных контрагентов и больше с ним не работайте.

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

Мой главный совет - не будь мудаком, как в данной ситуации, так и вообще по жизни.

Еще как вариант:

add_filter('gettext', 'translate_text');
add_filter('ngettext', 'translate_text');

function translate_text($translated) {
    $translated = str_ireplace('Related Products', 'Сопутствующие товары', $translated);
  return $translated;
}

Однако решение Александр Белькевич предпочтительнее.

За оснуву темы использую underscores.me

ACF не использую, т.к. предпочитаю чтобы конфигурация настроек для шаблонов, и общих настроек сайта производилась в файлах.
Для этого использую carbonfields.net, он бесплатный, но в нем есть все что нужно, смотрите документацию и раздел на wp-kama(он по старой версии, но часть еще актуальна).
Он не такой популярный, но со своей задачей справляется отлично.
Возможно в нем есть свои минусы, но для небольших сайтов отлично подходит.

Как второй вариант можно использовать Meta Box, но за некоторые фишки в нем прийдется заплатить.
Например общая страница настроек сайта создается с помощью платного расширения плагина

Изучать - Кодекс WordPress, а за основу можно брать https://underscores.me/

Этот хорош, автор пишет все без плагинов, дает понимание как все работает -
https://www.youtube.com/watch?v=ViZLtFIcSfo&list=P...