estic

Не создает, если размещена на локальном интерфейсе (loopback, etc.). Ест ресурсы, в основном когда работает. А работает не часто. (Еще прошлый раз хотел пошутить: "Место на диске решили сэкономить?" Но похоже тут все серьезно 😀) Если бы речь шла о каком-то десктопном клиенте, здесь бы, естественно, вопросов не было. Но это Web-панель на типичном серверном языке. Ее можно было бы разместить удаленно, если бы ваш компьютер использовался как Web-сервер в VPN. Хотя даже в VPN лучше держать PMA и базы данных в одном сегменте.

Я, например, понимаю. Но PMA лучше держать на том же сервере, что и базу данных (или хотя бы в той же сети, если у вас все распределено по разным серверам). Зачем ее "носить с собой"?

Вам предложили подключить к ней PMA по SSH. Т.е. прямой доступ остается локальным на сервере. Не безопасно "выставлять панели наружу", о чем я вам ранее писал.

Можно и старый каталог C:\Certbot использовать. Только симлинки в C:\Certbot\live\domain.tld нужно восстановить вместо копий файлов. Пример для командного файла:

mklink C:\Certbot\live\%1\cert.pem C:\Certbot\archive\%1\cert%2.pem
mklink C:\Certbot\live\%1\chain.pem C:\Certbot\archive\%1\chain%2.pem
mklink C:\Certbot\live\%1\fullchain.pem C:\Certbot\archive\%1\fullchain%2.pem
mklink C:\Certbot\live\%1\privkey.pem C:\Certbot\archive\%1\privkey%2.pem

Первый параметр - основной домен, второй - номер последнего выпуска сертификата.

Если сейчас используется ZeroSSL, то проще выпустить Let's Encrypt полной командой, как писали выше. Но старые файлы все равно лучше разместить на своих местах, чтобы выпускать под старым аккаунтом.

Про сервер на Windows 7 для Web-а не понял. Нужно использовать серверную ОС. При этом сертификаты можно выпускать Certbot-ом на домашней ОС и вручную устанавливать на сервер аналогично ZeroSSL. Для автоматической валидации можно использовать мой сервис вместо использования "аутентификатора" и записи чего-либо на ваш сервер в процессе валидации.

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

Совсем уж "зоопарк" тоже устраивать не нужно, а то "натянете" много лишнего и "конфликтного".

PHP-фреймворк для фронтэнда? 😊

Да. Про PMA по ссылке в панели не помню (наверное, тоже). Я ispmanager и т.п. не использую за ненадобностью. PMA отдельно устанавливаю, когда нужно. Обычно использую HTTP, т.к. этот трафик во что-то завернут 😉

В CMS (в смысле в панелях управления содержимым, в административных панелях) сейчас многое делается "на фронте". В головной части тоже, если нет цели придерживаться какой-то совместимости. Можно даже двойственное поведение реализовать для поддержания совместимости.

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

Конечно, мы все примерно понимаем, о чем вы пишете, но все-таки вы слишком вольно используете термины.

CMS создаются с использованием фреймворков. Фреймворки бывают "самописные".

Самоподписанного достаточно. Но лучше подобные панели не отображать во вне, т.е. разместить на локальном интерфейсе (loopback, etc.). Для доступа соответственно использовать SSH-туннель или VPN.