Иван Корюков

запускать каждые 10 секунд - не слишком выгодно.

Напишите себе демона и пусть он все время работает с банальной паузой или сверкой timestamp.
А в кроне просто периодически проверяйте запущен он или нет.

PAC manager.

По сути нужна несложная обертка над консольным ssh, чтобы не запоминать, на каком хосте какой порт (если нестандартный) и какой приватный ключ используется (это есть в истории команд, но все же).

Но гуй для этого - оверкилл. вкладки есть в любом эмуляторе терминала, а вот то все остальное легче закинуть в ~/.ssh/config, еще и короткие алиасы появятся:

host tts
    hostname 10.0.10.0
    user support
    port 22222
    identityfile ~/.ssh/id_rsa_sup_2018
host ...

Включи отображение ошибок или смотри error.log
Там будет написана причина, что переменная $pdo не определена.

А почему вы по умолчанию public не ставите, если выбираете между public и private? Наверное потому что вам инкапсуляция нужна?

Ситуация с дочерними классами ничем не отличается. Не стоит делать метод protected по умолчанию по той же причине, по которой его не стоит делать public по умолчанию.

1. написать функцию
2. она делает то что хотите? если да, профит. Если нет - назад к п.1

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

Далее - как понять что использовать? для начала нужно понять, что вы хотите.
Выясняете <что я хочу>. Выясняете, <где это должно быть>. Гуглите как сделать <то что я хочу> в <где это должно быть>.

1. Правильно ли будет, если на этот сервер разработки я поставлю GitLab?
2. Насколько помню, центральный git-репозиторий обычно хранят на отдельной машине (ну или на github.com).

Вы ни когда не задумывались, с чем это связано? :)

На самом деле, GitLab, не очень "спокойно" работает, если его проксируют, возникает целая череда "танцев с бубнами", что бы он нормально работал. Это первый момент.

Второй момент, напрямую связан с первым - GitLab любит, что бы сервер был целиком в его распоряжении. Если не уходить далеко в подробности, можно поставить GitLab на какую-то виртуальную машину (например, LXC/LXD), а сервер разработки - на вторую виртуальную машину, и всё это будет работать в рамках одного сервера. В этом случае, кол-во "потенциальных проблем" сводится к нулю, но, крайне желательно иметь 2 разных IP, что бы избежать проксирования (и каждой машине выделить свой IP). В ином случае, мы опять упремся в HTTP-прокси со всеми вытекающими...

Ещё один важный - GitLab очень любит ресурсы сервера и обычно требует не менее 1-2Гб оперативки... Которые, разумеется будут "откушены" от сервера и не смогут использоваться другими приложениями. А так же, на сервере будет "паразитная" нагрузка создаваемая самим GitLab'ом и когда кто-то решит выяснить, "почему всё тормозит" - сделать это будет не так просто, как хотелось бы, т.к. на сервере, кроме вашего приложения будет работать GitLab...

Отвечая непосредственно на Ваш вопрос - "можно ли так сделать?" - можно. Но не стоит.

В первом случае передается значение скалярной переменной. И ее изменение остается в рамках функции.

Во втором случае передается список, который является фактически ссылкой.

В таких языках как С есть явное и однозначное управление тем что передается в функцию. Если хотите чтобы значение в функции менялось - передавайте ссылку на значение, не хотите изменений - передавайте само значение. Правда и внутри таких двух функций надо использовать разные нотации для доступа к таким переменным.
В Python все немного упрощено, и поэтому возникают такие неоднозначности. В нем к примеру значение 1 у всех переменных, которые это значением имеют, хранится в одном и том же месте. Но вот значение 30000 в одной переменной и то же значение 30000 в другой, будут хранится в разных местах.
Есть еще много всяких нюансов проистекающих из упрощений Python-а.