ThunderCat

Каждая защита отличается. Собственно иначе ее бы парсили кому не лень. По этому и подход всегда будет разный. Для начала надо смотреть не результат парсинга, а результат запроса, собственно что получено от сервера, включая код ответа.
Далее уже думать, смотреть что отдает браузер и что он при этом передает в заголовках.
И так до полного просветления.

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

когда авторизируюсь не выводит имя пользователя, честно уже задолбался гуглить, норм ответа найти не могу никак) грубо говоря у меня тупо по кд кнопка логина висит и все

Что делать в таких случаях? Во первых - сделать var_dump($_SESSION) и посмотреть что там лежит. Подозреваю что нужных ключей в этом массиве нет (или же они не там где вы их ищете, ну или называются иначе). Так же, неизвестно как вы делаете логин, и что при этом попадает в сессию (кстати - зачем хранить пароль в сессии - отдельная загадка). Рекомендую провернуть ту же операцию - проверить что в сессии после логина, ну и в коде логина убедиться что туда добавляются эти ключи.

радиокнопка ончейнж функтион(){
  форма.субмит()
}

если я правильно понимаю, прописан именно относительный путь: href="main.css"

Данный "относительный" путь будет работать только с файлами в одной директории. Относительный путь для файлов на хостинге в идеале должен быть указан от корня сайта, например /css/main.css, где первый слеш указывает на корень носителя, на диске это будет корень раздела (то есть аналогично c:\css\main.css в среде виндоус, или прям от корня разделов в линухе), в вебе это корень сайта - https://mydomain.tld/css/main.css.
То же самое для изображений в файле стилей, но там чаще всего идут от расположения самого файла, из которого запрашивается картинка, что-то типа ../images/bg.png, где .. означает "на уровень выше текущей папки", /images/ соответственно папка где лежит ресурс. В такой записи проще привязывать пути для изображений, независимо от папок, куда будут класть цсс, главное чтобы структура вложенности папок оставалась такой-же.

https://towardsdatascience.com/8-examples-to-query...

Шорт теги?

В видеоуроках, в статьях, я часто вижу, как PHP разработчики используют файл .htaccess как часть системы, часть сайта.

На то они и уроки/примеры. Рабочие конфигурации для любого сервера обычно тоже есть в туториалах чуть сложнее чем "давайте напишем хеллоу ворлд".

Но .htaccess работает только с Apache.

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

Почему разработчики не пишут код, который был бы универсальным для всех веб серверов и не делегировал часть функций безопасности конфигурационному файлу конкретного веб сервера?

по тому что единая точка входа не реализовывается программными средствами?

Не проще ли дописать дату создания сесcии и в запросе указывать интервал не более (жизни сессии)/(N суток)?
Алсо, можно удалять старые записи, если они не нужны для каких-либо статистик/метрик.

Как это можно сделать?

Средствами sql никак. Либо написать скрипт на 10 строк по перегону в нормальный формат, либо страдать ручками.

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

Апдейт юзерс
сет текст = "какой-то текст пришел из формы"
вэа айди = юзерайди_полученный_допустим_из_сессии

1) id="btncontcall" у вас повторяется в каждом выведенном элементе. По стандарту (да и чисто по логике), id - уникальный идентификатор (где уникальный - ключевое слово). На странице должен быть только один элемент с таким значением. Что легко проверить, заглянув в консоль и увидев кучу предупреждений о дублирующихся идентификаторах.
2) Не надо вешать обработчик на кнопку, вешайте на форм.субмит. Естественно айди формы тоже должно быть уникальным. Хотя в вашем случае айди вообще использовать не нужно, используйте либо класс, либо, что в данном случае гораздо логичнее, собственно тег form - $('form').on('submit', function(e){...});, в этом контексте this внутри функции будет сразу целевой формой, не надо выкрутасов с поиском текущей формы.

Тем более что ищете вы всегда первую, даже в неправильном коде: var form = $('#callbacks')[0]; всегда вернет первый элемент из списка форм, даже если там все будет правильно выбираться по идентификаторам.

Так, нихчего не понятно, но очень интересно...
Вам нужен локальный сайт(?) с возможностью заливать туда файлы? Или размещать ссылки на локальные сетевые ресурсы? И что за папков вы хотите там размещать? Если речь про ссылки на локальные ресурсы, то с папками еще как-то получится состыковать, а как вы себе представляете закачку папок на сайт?

Файлы при нажатии на раздел хочу отображать в попап окне.

Какого типа документы вы хотите размещать? С картинками и попапом еще ок, что будет с, например, вордовским доком/ехелем?

По описанию сильно похоже на вики движок.

Можно я внесу немного конструктивной критики в ваш вопрос, ну и сделаю некоторые выводы, возможно вам они будут полезны...

Я занимаюсь разработкой интернет проектов. Сейчас вместе с командой специалистов мы готовимся к разработке большого и высоконагруженного проекта.

Вы же не рекламное письмо фирме пишете, говорите четко - "у нас есть 6 маркетологов, джун верстальщик и эйчар". Ну или " У нас было два пакетика травы, семьдесят пять ампул мескалина, 2 явиста мидла, 2 пхп сеньера, бухгалтерия, наполовину наполненная старушками с калькуляторами, и целое море различных специалистов по яваскрипту, цсс, хтмл и их комбинациям в ассортименте, а так же...".
Тогда понятно - что вам искать, какие спецы какого уровня у вас уже есть и стоит ли их менять или строить будущую архитектуру под уже имеющийся состав.

Общая концепция выглядит приблизительно так:
Будет много разных баз данных, в которых будет храниться информация разного типа, текстовая, . Каждая база будет содержать информацию по разным темам.

Информация графическая, видео и аудио типов чаще всего не хранится в бд. Если вы не программист/архитектор IT структур - поручите вопросы архитектуры и структурирования данных кому-либо из команды, кто в этом разбирается (если таковые есть).

Отдельно будет полнотекстовая поисковая система объединяющая информацию из всех источников.

В принципе не особо зависит от стека, тут больше архитектурно-проектировочная задача.

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

Тоже самое - больше архитектура, нежели стек.

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

На сегодняшний день есть 4-5 хорошо распространенных языка, используемых в вебе: пхп, ява, жс, питон, в меньшей степени c#, руби, голанг, остальные больше экзотика, нежели мэйнстрим.

- Высокая производительность и многопоточность.

Которая в вебе не особо нужна, хотя практически все вышеперечисленные языки в той или иной мере многопоточность поддерживают. Опять же - сразу "видны уши" вашей недостаточной компетентности в вопросах разработки высоконагруженных проектов. Дело в том что в 99% случаев код именно языка программирования особо не нагружен. Больше всего процессорного времени будет съедаться запросами к бд и внешним сервисам. Код просто прослойка между фронтом и бд, чаще всего просто выполняющая задачи CRUD прослойки.

- Простая масштабируемость.
- Актуальность на ближайшие 2-3 года.

Везде подходит

- Интеграция с проектами написанными на других языках.

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

Постарайтесь пожалуйста привести аргументы в пользу того или иного выбора, а так же возможные минусы.

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

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

так как мне передать это имя пользователю

Из всего диалога в комментариях должен быть вывод:
1) урл файла для скачивания может быть любым, его трогать не надо.
2) Чтобы файл скачался под нужным именем, в заголовки нужно добавить принудительное переименование на клиенте

header('Content-Disposition: attachment; filename="' . $meta['name'] . '";', false);

, где $meta['name'] - имя под которым должно сохраниться у пользователя.