ThunderCat

Кошмарус максимус...
ладно все в лапше функциями, так еще и
1) в одной функции все в кучу - запросы, обработка, вывод...
2) это вы в каждой функции будете создавать / закрывать соединение где надо из базы 1 запись вытащить?
3) строка С ЗАПРОСОМ передается ПО ССЫЛКЕ, Карл!(экономим память епта!). Запрос как аргумент функции - вообще новое веяние...
4) при этом делаем: $query = $string; ... Не, ну а чо...

$GLOBALS это ваще жесть конечно... как и вставка гданных из гет в запрос(даже с какой-то обработкой), у вас же препэйреды по идее должны работать!

$STH = $GLOBALS["mysqlcon"]->prepare("
SELECT count(id) as count
FROM `post` 
WHERE MATCH (tags) 
AGAINST ('".clearStr($_GET['search'])."' 
IN BOOLEAN MODE)");

UPD: вам в любом случае придется делать 2 запроса, так как количество результирующих строк разное, кроме того каунт по первичному ключу будет быстрым, а выборка скорее всего сразу закешируется после первого запроса.

Тут еще и вопрос - "ошибка связана с неудачей в поиске чего-либо" - если это какая-то выборка пустая, то никакого особого ответа не нужно, просто пишете что "ничего не найдено", код 200. Ексепшн бросаете только в случае когда допустим файл ДОЛЖЕН быть по логике приложения(например на него есть запись в бд), но физически его на сервере нет. Это уже исключение, в случае же пустого результата поиска никакого эксепшна нет, это не исключительная, а штатная ситуация.

7 == intval($attribute_group['attribute_group_id'])

Никак, все что попало на клиент = уже есть у клиента, в самом сложном случае я просто открою консоль нетворка и скопирую сырые данные приходящие с сервера.

В принципе есть всего 2 варианта, оба варианта выше написали.
1) уникальный ключ по 2 полям
2) Селект по этим же полям и проверка на стороне ЯП на наличие записи

Оба варианта работать будут, однако я бы все же советовал бы использовать 2 вариант. Не смотря на то что вариант 2 имеет некоторую возможность коллизий(как верно заметил Rsa97), он не вызывает неоднозначности в выполнении, то есть он явно проверяет наличие строки, в то время как первый метод вызывает ошибку вставки по уникальному ключу на стороне БД, что гораздо сложнее обрабатывать. В целом ничего не мешает скомбинировать оба метода, тогда коллизий можно избежать, максимально ограничив количиство возможных ошибок предварительной проверкой.

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

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

Удалив модуль и БД мы повлияем на работу других модулей. Изменив структуру БД мы повлияем на работу других модулей.

SOLID, DRY, KISS...PSR4 и много других страшных аббривиатур вам помогут )

Классический DI

class App{
  protected $db;
  public function __construct($db){
    $this->db = $db;
  }
}

$data = file("file.txt");
$uniq = array_unique($data);
file_put_contents("newfile.txt",implode("\n",$uniq));

код вполне юзабелен, не шедевр, но работать будет, хотя имхо слишком узкоспециализирован.
Кроме того - логичнее не строить клин вложенных проверок, а создавать "отсечения", типа:

public function dbGetRecordsToTableByColumn($table, $column, $value) 
  {
    if (empty($table)  || empty($column) || empty($value)) return [];
    if (!$this->searchTableToArray($table)) return [];
    if (!$this->searchColumnToArray($column, $table)) return [];
    return $this->db->row("SELECT * FROM `{$table}` WHERE `{$column}` = :{$column} ORDER BY `id` DESC", [ 
       $column => $value
     ]);
  }

если именно страна - geoIP
если достаточно язык браузера - $_SERVER['HTTP_ACCEPT_LANGUAGE']

Шэдевр ) елс без ифа - новый тренд )

$id = $_GET['id'];
$posts = R::load('posts', $id);

R::trash($posts);

echo 'udalos';
else { echo 'ne udalos'; }

Не получается

у девочек на корбке механике "не получается", что конкретно происходит? Ошибки, результаты?

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

$('#upload-image').on('submit',(function(e) {
                e.preventDefault();
                var formData = new FormData();
                formData.append('image',$('#image')[0].files[0]); 
                $.ajax({
                        type:'POST',
                        url: './modules/image-update-handler.php',
                        data: formData,
                        cache:false,
                        contentType: false,
                        processData: false,
                        success:function(data){console.log('success');},
                        error:function(data){console.log('error');}
                });
        }));

на бэкэнде:

//тут код который добавит комментарий, а далее
$sqlComm = 'SELECT comments.id, comments.author_id, comments.date, comments.text,
        comments.post_id, users.name FROM comments
        JOIN posts ON posts.id = comments.post_id
        JOIN users ON users.id = comments.author_id
        WHERE posts.id = ' .  $_GET['id'] .
        ' ORDER BY comments.date DESC';
$comments = $db->query($sqlComm);

foreach ($comments as $comment) : ?>
            <div class="comments">
                <div class="row comtext">

                    <div class="comname">
                        <?=$comment['name'];?>
                        <br>
                        <?=formatTime($comment['date']);?>
                    </div>

                    <div class="comtent">
                        <?=$comment['text'];?>
                    </div>

                    <div class="delete">
                        <button class="btn btn-sm btn-outline-light"  id="<?=$comment['id']?>">Удалить</button>
                    </div>

                </div>
            </div>
            <? endforeach;?>

на форнте:

// кусок который аякс с отправкой коммента
.done(function (data) {
$('#comments_box').html(data); // здесь comments_box - ид врапера коментариев
})

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

В вашем случае данные пришедшие с клиента просто должны проходить через фильтр (что является обязательным в любом случае) + на каждое действие с объектами для которых нужны права админа проверять если таковые права есть, и уже исходя из этого прерывать работу или продолжать обработку.

UPD: если ОЧЕНЬ нужно выводить в js какую-то строчку для админа, то перед загрузкой скрипта вашего аякс запроса добавьте:

<script>
<?php if($adminLogged){ ?>
let val3 = $someSecretValue;
<?php } else{?>
let val3 = false;
<?php } 
</script>

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