Игорь Воротнёв

Проблема в области видимости - переменная $mysqli недоступна в функции fakePayout(). Решается одним из способов:

1. Явной передачей переменной внутрь функции function fakePayout($mysqli, ...) {
2. Корректным доступом к данной переменной, поместив ее в свойство класса, содержащего функцию fakePayout():

class SomeClass 
{
    private $mysqli;

    public function __construct(DataBase $mysqli)
    {
        $this->mysqli = $mysqli;
    }

    public function fakePayout($user, $amount, $time)
    {
        // Теперь можно использовать
        $this->mysqli->query()
    }
}

3. Вариации #2 с dependency injection контейнерами, фасадами и прочее.

ЗЫ: Можно еще внутри самой функции создавать соединение, или хранить его в глобальной переменной / синглтоне - но это уже совсем дичь.

1. Зарегистрировать ИП
2. Выводить деньги на банковский счет ИП
3. Платить адекватные налоги
4. Не париться и жить как живут белые люди в 2019м году
5. Профит!

Если кто-то возразит что, мол, налоги-то оплачивать придется - угу, придется. Но тут есть пару моментов:
- Не знаю сколько там у вас в РФ, у нас в УА это 5% от оборота + ЕСВ в размере около $35/мес.
- На переводах, выводах и конвертациях, комиссиях через все эти пейониры, вы в итоге потеряете плюс-минус столько же.
- Внезапно, физлицу тоже налоги платить надо. При чем там проценты повыше. Не платите - значит уклоняетесь от уплаты налогов, то есть нарушаете законодательство и является банальным преступником. Юридически. Да, на небольших суммах через пейонир вас вряд ли налоговая поймает, но это никак не меняет того факта, что вы нарушаете закон - получаете доход как физлицо и уклоняетесь от уплаты налогов с этого дохода.

Laravel, Digital Ocean - все это не существенно и не имеет никакого значения. Конфигурация производится на уровне веб-сервера Apache или Nginx. Какой у вас сервер стоит?

Все обучающие материалы, примеры, боилерплейты и тд под Лару 5.* подойдут. В 6й версии не так много изменений, которые касаются пользовательского кода, и все они описаны в Upgrade Guide.

С помощью хрустального шара.

https://github.com/ihorvorotnov/sonata

Давно не обновлял код, многое нужно освежить, но концепция думаю понятна.

Что важно понять - просто разложить отдельно вообще в разных местах темы и все остальное не получится, разве что симлинками. Ядро будет искать конфиг на 2 уровня вверх, некоторые пути (контент, как вы уже поняли) будут отсчитываться от рута (где конфиг).

Все требуют дополнительного кодирования

Боюсь, без дополнительного кодирования не обойтись, при чем объем превышает возможность ответить вам на Тостере - это серьезная и объемная задача.

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

она может быть не заполнена (null).

Она заполнена. NULL это валидное значение, такое же как и любое другое.

или сделать отдельную таблицу с этой колонкой

Лишнее. Это дополнительный запрос или JOIN. Выигрыша ноль.

Почитайте про кардинальность. Нету ничего плохого в том, чтобы часть записей имело NULL в колонке, которая не является обязательной. Вот если таких колонок становится много и их все условно можно отнести в категорию secondary/metadata - например, они не используются на выводе "все пользователи" (индекс), а нужны только при просмотре одного конкретного пользователя - вот тогда можно думать о том, чтобы выносить эти данные в отдельную таблицу. Например, будет users и user_data, в которой и будут эти колонки. На индексе вы будете запрашивать только users, на одном пользователе - обе таблицы.

Попробуйте:

$args = [
    'meta_key' => 'start_date',
    'meta_type' => 'NUMERIC',
    'orderby' => 'meta_value_num',
    'order' => 'ASC',
];

Добавить в wp-config.php:

define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');

И очистить кеш и куки.

У вас мультисайт?

755 это права для директорий, для файлов 644 и еще более жесткие. Для самих "программ" права вообще другая история, здесь нужен executable bit (chmod +x) в первую очередь. Пользователь, который данные "программы" запускает должен иметь права на исполнение. Кроме этого, файлы которые нужно брать в работу должны иметь права на чтение для этого пользователя, а директория, куда будут складываться оптимизированные картинки - права на запись для этого пользователя.

В вашем конкретном случае я так понимаю сам модуль делает проверку и говорит что либо у него нет прав выполнить optipng/jpegotim/etc, либо директория, куда ему надо складывать результаты недоступна для записи.

1. Получить контент из базы данных - с помощью get_post() например.
2. Регуляркой вырезать нужный фрагмент - все что начинается с <тег id="идентификатор"> и заканчивается закрывающим тегом.

Если это разовая задача, быстрее всего будет скопировать весь код из редактора WordPress в ваш настольный редактор кода, поиском-заменой изменить все img на a>img с нужными ссылками (тут помогут регулярки в поиске-замене). Потом скопировать результат обратно в редактор WP.

Как уже написали, универсального набора не существует, ибо задачи разные. Но есть некоторые наметки по этому поводу. Сразу оговорюсь - у меня всех без исключения WP-проекты построены на базе Composer, зависимостями (а плагины ими и являются) управлять просто и удобно, плюс autoload. Это позволяет динамически включать-выключать плагины в зависимости от переменных среды или feature flags. А теперь сами плагины. Разобьем им сразу на 2 категории - development и production. Первые нужны для облегчения разработки и отладки проекта, вторые - всегда.

Development-only плагины:

- Query Monitor
- Transients Manager
- WP Crontrol
- Airplane Mode
- Debug wp_redirect
- User Switching
- Rewrite Rules Inspector
- rarst/wps (обертка для Whoops)
- rarst/laps (профайлер)
- Regenerate Thumbnails
- Парочка кастомных mu-plugins которые облегчают жизнь (обертка для symfony/var-dumper и тд)

Production:

- ACF Pro
- Кеширование - WP Super Cache, Batcache, WP Fastest Cache. Redis/Memcached для объектного кеша (все есть от именитых команд типа 10Up, Humanmade и тд) - какой конкретно зависит от проекта
- Для форм использую свою наработку, HTML чистый который делает верстальщик, обработчик - своя кухня которая использует внешний transactional email service (SendGrid, Amazon SES и другие - адаптеры пишутся по необходимости) с их темплейтами для писем, использует composer-библиотеки для валидации и тд. Для всех форм также создается custom post type, все сабмишны пишутся туда с логом (сами данные формы, статус отправки транзакционного письма, лог мейлера и тд - удобно для отладки). На первый взгляд звучит сложно, но благодаря ООП-архитектуре по принципу Laravel / Laravel Nova все настраивается буквально за считанные минуты. Но если бы использовал готовый плагин, то скорее всего CF7.
- Disable Comment - потому что на большинстве сайтов они не нужны
- Classic Editor - потому что все еще не везде подходит/заходит Gutenberg
- Duplicate Post - удобно для работы с контентом, активируется по необходимости
- Enable Media Replace - иногда полезен, активируется по необходимости
- EWWW Image Optimizer Cloud - удобно, дешево
- Lazy Load Optimizer - полезная штука для frontend performance
- Safe SVG - SVG сейчас везде, так что без него никуда
- Cyr-To-Lat - если сайт кириллический / мультиязычный
- Для мультиязычных сайтов чаще всего останавливаемся на WPML
- ElasticPress - для поиска/фильтров
- WP-Minions или Cavalcade - для асинхронных фоновых задач
- humanmade/S3-Uploads - для медиа-библиотеки в S3

Дальше, для разных задач есть свои "фавориты" и/или свои кастомные наработки.

Ну и, конечно же, WP CLI.