estic

Я, например, понимаю. Но 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.

Не суть. Можно и так, если это проще реализовать. Хотя я писал о специальных "категориях", так что можно и так: /category/krasnye-sloniki. А если магазин поддерживает теги, то и никакие специальные "категории" не нужно выдумывать: /tag/krasnye-sloniki. Причем вовсе не обязательно использовать типичную теговую реализацию для таких случаев. Можно опять-таки внедрить в теги обычный фильтр для получения части результатов.

В общем же отдельные результаты фильтрации можно открывать для индексации, что по моим критериям позволяет использовать просто /krasnye-sloniki 😉