estic

У каждого типа свое основное назначение.

1) для base или когда явно нужно указать относительные (и нет base). Актуальность в использовании относительных сейчас мала, но они по-прежнему часто используются, как наследие прошлого (и часто создают проблемы).

2) основной тип для шаблонов и т.п.

3) редко используется; в основном когда нет переадресации на адреса со схемой https.

4) основной тип для содержимого, но в общем типы 2 и 4 взаимозаменяемые.

От чрезмерного потребления пищи вы не станете великаном, а быстро "загнетесь".

Оптимальную методику "для ленивых" я описал в предыдущем сообщении.

Как выше написали, включать "выполение" html-файлов на PHP небезопасно. Используйте специальный скрипт для обработки запросов с .html в адресе. Или в крайнем случае сделайте так, чтобы запросы с .html в адресе обрабатывались в соответствующих php-файлах (при их наличии). А чтобы не было дублей /page.html и /page.php, разместите php-файлы в каком-то "скрытом" каталоге.

В последний раз: не нужно так делать.

Тоже иногда занимаюсь "восстановлением дропов" в облегченном варианте. Вместо восстановления страниц можно использовать информативную страницу ошибки 404, например с точной копией главной, и индивидуальную переадресацию с отдельных "интересных" адресов. А от того, что вы хотите сделать, будет только вред.

На соответствующие страницы, т.е. на страницы с примерно таким же содержимым, какое было раньше. Эти другие страницы могут размещаться на другом (или других) домене. Донор может быть даже одностраничником с индивидуальной переадресацией по отдельным внутренним адресам или без такой переадресации. Простейший пример - estic.ru сейчас. Одинаковое содержимое по всем (или почти всем) адресам, но главная все же отличается от внутренних 😉

Не нужно. Для пользователей можете выводить на странице ошибки 404 любое полезное содержимое. Возможно, разное содержимое по разным адресам или даже по одному и тому же адресу.

Не нужно так делать. Можно попробовать использовать переадресацию на JS или при помощи нестандартного заголовка Refresh, но даже это выявляется и не приветствуется поисковыми системами.

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

Я тоже обычно работаю по SSH и т.п. Но ведь к PMA на сервере можно подключиться таким же способом. По возможности "посредников" лучше размещать ближе к "телу", независимо от того, реализуют ли они прикладной интерфейс или пользовательский.

...Или вы боитесь, что сама PMA может содержать вредоносный код?

Вы поняли неправильно. Я Web-программист. Также занимаюсь администрированием MySQL, MS SQL (Server). SQL-аналитика, естественно, прилагается.

Так я и говорю, что PMA - не ваш инструмент. Я тоже могу редко используемую (с непредсказуемой периодичностью использования) Web-панель "снести" на сервере, а в случае крайней необходимости подключить ее удаленно (если панель легко подключить удаленно и к ФС сервера). Но если вам требуется работать с подобными панелями с определенной периодичностью, то лучше их держать на сервере. Или периодически устанавливать и "сносить" 😀

Административные Web-панели вообще не используете на "проде"? Десктопные что ли панели?

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