4X_Pro

Я бы посоветовал вот что: попробовать несколько CMS, обращая внимание, в первую очередь, на пункты 4 и 5: хватает ли возможностей CMS для обеспечения нужных вам разграничений привилегий или нет. Если найдете подходящую, то дальше останется дописать недостающие модули, если нет, то придется писать свое.

Если у вас VDS, то по умолчанию логи Apache, скорее всего, включены и лежат где-нибудь в /var/log/apache2 или /var/log/httpd. Если обычный хостинг, то скорее всего, в каталоге /logs в корне.
Но по ним можно увидеть только тот php-файл, который запускался напрямую, а подключаемые через include/require там не появятся. Если нужно отслеживать и их тоже, то воспользуйтесь функцией get_included_files(), и допишите в конец каждого из вызываемых скриптов код, который будет писать список подключенных файлов в лог.
Код примерно такой:

$files = join(',',get_included_files())."\n";
$fh = fopen('php.log','a');
if ($fh) fputs($fh,$files);
fclose($fh);

Посмотрите, нет ли чего подозрительного в cron (причем как под rootом, так и под пользователем, от имени которого работает сайт), например, криво написанного скрипта для backup.

Скорее всего, config.php сохранен в текстовом редакторе, который добавляет символ BOM в начало файла. Тогда надо в настройках редактора это отключить и пересохранить файл заново.
Еще вариант — добавить в начало скрипта (до require) вызов функции ob_start для буферизации выводимых данных, это может серьезно облегчить жизнь в дальнейшем.

Это из-за так называемого strict mode, включающего ряд дополнительных проверок, в том числе невозможность записи строки в double. В консоли он по умолчанию включен, в PHP — выключен.
Чтобы его отключить, нужно сделать запрос
SET SESSION sql_mode = '';

Не очень понятна задача. Если нужно конкретно эту картинку загрузить, то можно открыть ее в каком-то графическом редакторе и сохранить заново (либо сконвертировать в PNG, а потом обратно в JPEG на своем компьютере), а потом загружать.
Если требуется убрать предупреждения при загрузке поврежденных картинок вообще, то нужно поставить @ перед imagecreatefromjpeg.

Кроме БД, проблемы с кодировкой могут быть в других местах.
Во-первых, на сервере. Если это Apache, то имеет смысл прописать что-то вроде AddDefaultCharset utf-8 в .htaccess
Во-вторых, проверить, не используется ли шрифт, не поддерживающий кириллицу.
В-третьих, попробовать прописать в начале скрипта ini_set('mbstring.internal_encoding','UTF-8'), чтобы не возникало проблем при обработке строк в самом PHP.

Скорее всего, у вас остаются невыбранные данные после выполненных запросов. Сделайте после всех SELECT-запросов mysqli_free_result($res).
Автоматически соединение может не закрываться, если PHP работает с использованием persistent_connections (а также, возможно, в режиме FastCGI, но точно не уверен, нужно документацию смотреть).

Зависит от того, возможен ли одновременный приход данных из разных источников (скажем, два пользоваеля сразу обратились к сайту). Если да, то лучше SQL, так как без него придется самостоятельно делать блокировку файла, чтобы не получилось так, что оба пользователя пишут одновременно. Но базы данных SQL вполне можно поместить и на SSD.
Вообще, информации, конечно, маловато, но так сходу могу предположить, что лучше всего на данном этапе вам подойдет SQLite.

Тут есть два варианта. Первый — пользователь заходит через IPv6, а скрипт пытается преобразовать его адрес с помощью ip2long, который корректно понимает только IPv4. Второй — пользователь заходит через proxy, который что-то передает в X-Forwarded-For, что некорректно преобразовывается в IP-адрес (например, передает не IP, а доменное имя).
Чтобы этого не было, нужно сохранять IP не как число, а как строку, причем сохранять туда и $_SERVER['REMOTE_ADDR'], и $_SERVER['HTTP_X_FORWARDED_FOR'] (тогда как многие скрипты при наличии второго REMOTE_ADDR просто отбрасывают).