Алексей Уколов

Сейчас у меня каждый компонент помещает результат в собственный скрытый input, но как-то эстетически мне это не нравится...

И почему же? Я тоже так делал. Но чаще даже отдельный скрытый инпут не нужен.

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

То есть по сути никакой PDO::PARAM_CLOSURE для того чтобы изменить данные на лету не нужен - ты тупо меняешь значение приязанной переменной. Именно благодаря передаче по ссылке.

$stmt = $pdo->prepare("SELECT ?");
$stmt->bindParam(1, $var);
$var = 1;
$var = 2; // меняем на лету
$stmt->execute();
$var = 3;
$stmt->execute();

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

Простейшее веб приложение уже не отразит суть всех тенденций. Или его сложно будет назвать простейшим) Правильно советуют phptherightway, из этого обязательно стоит отметить:
- стандарты psr
- сборка проекта через composer, знание самых популярных пакетов и где их искать
- знакомство с IoC (Di) контейнером
- знание хотя бы одной популярной ORM
- уверенная работа в IDE (погуглить основные лайфхаки пхпшторма)

Обычно пара официальных вводных курсов по фреймворкам знакомит со всеми этими вещами. Yii2 давно отстает от тенденций

Открыть файл в Google таблицах и настроить пустую ячейку для перевода вставив в него "=GOOGLETRANSLATE(A1;"uk";"ru")", далее потянуть за край ячейки в низ до нужного поля.



Пример документа

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

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

- использование РНР в мире
- использование РНР в качестве шаблонизатора
- проецирование своего микроскопического опыта разработки микроскопических страниц на всю разработку в целом.

Поэтому отвечать надо на все три вопроса по отдельности

1. РНР в современном мире используется очень по-разному. Можно очень грубо разделить на 4 группы
- многочисленная армия клепальщиков готовых сайтов на конструкторах типа Битрикса, Вордпресса, Друпала, Маженто и весь прочий зоопарк
- довольно многочисленная армия тех кто не смог освоить даже предыдущий пункт, и до сих пор старательно выводит по слогам "вайл муэскуэль фетч эррэй"...
- относительно малочисленная группа освоившая современные методы разработки включая фреймворки, поставившая напиливание сайтов на поток
- довольно малочисленная группа программистов, которые пилят штучные проекты типа ВК, Баду, ФБ и прочий хайлоад

2. использование РНР в качестве шаблонизатора
Опять же, зависит от группы, к которой ты относишься, но на практике встречается только в группе 3.
Остальные уже научились использовать шаблонизаторы.

3. Не все проекты являются примитивным перекладыванием данных из БД в ХТМЛ. ООП "и другие возможности" нужны для написания сложных программных систем.

class Rate extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            date: '',
            currencyRat: {},
        }
        this.currency = ['USD', 'RUB', 'CAD'];
    }
    componentDidMount() {
        this.getRate(); // не в конструкторе надо вызывать, а в componentDidMount
    }
    getRate() {
        fetch('https://api.exchangeratesapi.io/latest')
            .then(data => {
                return data.json(); // забыли вызвать функцию
            })
            .then(data => {
                console.log(data)
                this.setState({ date: data.date })
            })
    }

[^\/]+(?=\/$)

Правильно - хранить код в одном репозитории.
На проде не требуется даже иметь гит или что там у вас в качестве системы контроля версий.
Нужно настраивать CI/CD так, чтобы в контейнер на прод выкатывались только нужные файлы и каталоги, ничего лишнего.
Очень удобно, когда в девелоперском окружении код работает без докера, но сопутствующие вещи вроде БД и прочих сервисов удобно держать в контейнерах и на девелоперской машине. Так проще развёртывать среду разработки и быстрее вводить сотрудников в процесс. Технически нет особых проблем, чтобы настроить удалённую отладку прямо внутри контейнера. так можно приблизить девелоперское окружение к продовой конфигурации.

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

Храните всё, что нужно для CI/CD в том же репозитории где код. Там же у вас лежат тесты (не нужные в продакте), вспомогательные скрипты, артефакты тулинга и прочее.
Поищите, в гитхабе есть много так называемых "КукиКаттеров". Это инструмент, для шаблонизации проектов на разных стеках. Как правило в созданной по такому шаблону заготовке проекта уже есть всё не обходимое для CI/CD.

Денис Загаевский прав, но если очень уж хочется увидеть похожий вывод в powershell...

ls | Format-Wide -Column 5 -Property name

1. Перепачатать и переклеить qr код
2. Сделать редирект со старого адреса на новый

Странно, что вы задаете вопрос здесь, а не тому, кто вам сказал, что "половина уже не нужно".

Хорошо, раз вопрос задан, внесу свои 5 копеек.
Вы выучили базовые принципы продвижения и без них даже не имеет смысла заниматься продвижением сайта. Кто говорит обратное, застрял в 2009 году, когда для достижения заветного ТОПа достаточно было увеличивать бюджеты на ссылочное. Сейчас тоже такие ребята есть и работают они на этот раз с "подливами" и накруткой ПФ. Всегда найдутся те, кто хочет быстрее срубить бабла на Заказчике..

"База" перечисленных вами работ/навыков была и остается, плюс к ней добавляется работа с Яндекс справочником и Google Бизнес, например, которые не относятся напрямую к SEO, но влияют на успешное продвижение в регионах.

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

сообщение->мой домен->редирект r01->гугл(спам)

Последовательно отмечать такие сообщения как «не спам» — возможно, со временем поможет.

Если не помогает или не хватает терпения, то в настройках Gmail создать фильтр «не помещать в спам» письма, содержащие в Кому полный адрес в своём домене или его часть (например, только домен). Если вы, как и я, предпочитаете упрощённый интерфейс Gmail, то создание такого фильтра в нём недоступно и для этого надо временно переключится на «стандартный». Письма будут помещаться во Входящие, но в своём большинстве будут содержать пометку, что не помещены в спам из-за соответствующего фильтра. Эту пометку убрать нельзя и явным образом дать понять Google, что это не спам тоже нельзя.

Можно также попробовать воспользоваться двумя ящиками в Gmail. Пересылать из своего домена на первый. Для него настроить ничего не помещать в спам, пересылать на второй и удалять, и больше в него не заходить. По моему опыту доля попавших в спам писем во втором (основном) ящике при таком двойном перенаправлении будет меньше, а их уже можно попробовать помечать как не спам вручную для обучения Google.