тупость в том, что скрины специально сделаны что бы показать что один файл просто директория и один index.php файл, нет ни движка ни фреймворка, потому что по прикладывая код текстом все и начинают умничатья вижу что запрос идет по локалхосту, а в скринах какой то dex.chank.php, это к "полезности" скринов.
ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);
if($_SERVER['REQUEST_METHOD'] == 'POST'){var_dump($_POST); exit();}
и после этого уже можно будет о чем то думать. А для других страниц не получится ли, что страницы "с внутренних страниц" ?Получится. По уму верный ответ будет "гарантированно - никак", но эти два механизма позволяют дать приблизительную точность определения. Реферер вообще не обязательный заголовок и его можно выключить или браузер его может не пересылать специально иногда, так что нет гарантированной схемы узнать перешел ли человек по ссылке внутри сайта или пришел по ссылке извне. Единственный более-менее действенный метод - генерация рандомных ключей, приписывать их в качестве гет параметров всем ссылкам на странице, а затем отслеживать их на другой странице. Но это уже из области редких извращений...
Переделаешь по-человечески - слетят ссылкитак а куда они денутся то? Слаг останется, структура выдачи не меняется, то что это будет работать через другой механизм на сервере на выдачу никак повлиять не должно. На выходе будет абсолютно тот же хтмл что и был, если кто-то в код шаблона не залезет ) Данные просто будут разложены более структурированно, но никуда не денутся...
это не структура таблиц, это тупой скриншот из РМА.и даже его достаточно чтобы сказать что там все криво. Для наколеночной поделки пойдет, но как только возникают вот такие тривиальные задачи, все какахи всплывают со дна...
В данном случае этого нет, на сайте 3 таблицы, юзеры, кастомеры и консультанты)Видимо они с разных уголков галактики, так как не имеют общих признаков, таких как имя/логин, пароль и например гендер, а область их ответственности вшита в генетический код и не может быть выделена в роли, перечисленные в отдельной таблице... Ну да, так часто бывает...
А потом все-таки наступает тот решительный момент, когда общее - кончается.Естественно, цена универсальности - повышающаяся сложность. Другой ворпрос что обслуживание 50 менее сложных проектов все равно сложнее 1 более сложной системы. Чем вникать каждый раз чем отличается релиз 30 от 45, проще просмотреть в конфиге набор включенных функций для 30 и 45. И 1 раз поправить модуль для 45 (который скорее всего еще и в 4 и 38 используется).
Мини-CRM же. Логика под каждого клиента, максимально близкая к его рабочим процессам.отличий не больше чем в плагинах вордпресса. Ядро полюбому достаточно универсальное, если на его основе делается 50 "разных" црм. Реально проще вынести хотелки в модули/конфиги и подключать по мере необходимости. Тот же 1эс примерно так и работает - на конфигурациях, обслуживая абсолютно разные предприятия на одном движке (вот уж не думал что когда-либо приведу 1с в качестве удачного примера...).
но оно ничего не делалоа что должно было делать?
this.classList.toggle('big')То есть вы кнопке задавали класс? Зачем?
По вопросу - ты явно не стандартной какой-то фигней пользуешься, как минимум вардамп так никогда не выглядит. Вывод - что-то из приблуд работает криво. Поставь стандартный пхп + апач/нжинкс, и все будет нормально работать.