ThunderCat

Как я понял есть:
- APC
- XCache
- OPCache
- eAccelerator (вроде не развивается с 2016)

Из них только OPCache более-менее актуален, а в 7 ветке это уже излишне в принципе.

- memchached (ставится в связке с кем-то из выше изложенных)

*memcached не относится к кэшированию кода, это хранилище. Если нужно - лучше использовать редис или какие-то альтернативы посовременнее.

include 'data/param.php;работать не будет, так как у вас кавычка не закрыта.

Во первых - что у вас называется пином? текст, число, какая длина и в каком формате хранится и для чего используется? Насколько это "секьюрная персональная информация"?

интеджер от 5 до 7 символов

В идеале, если это пин, он должен содержать какое-то определенное количество символов. Это удобно по многим причинам.

1 вариант - настроить таблицу на автоинкремент от какого-то пятизначного числа, сделать шаг автоинкремента отличным от единицы и использовать его в качестве пина. Минусы очевидны - привязка к ид, предсказуемость, пляшущая размерность. Плюсы - гарантированная уникальность.

2 вариант - генерация "налету", например через микротайм, или ранд, не суть. В таком случае конечно же не нужно делать проверку через do while, достаточно сделать селект со сгенерированным значением, если запрос вернул строку - перегенерировать, если вернул пустой результат - можно добавлять. В любом случае поле нужно сделать уникальным, дабы избежать повторений.

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

Грамотнее всего использовать готовые фреймворки, или хотя бы компоненты от популярных качественных фреймворков.

Так же нет необходимости закрывать соединение, оно само автоматически закроется по завершении пхп скрипта.

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

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

1) Оно мегахреново переносится и очень криво становится на свежие системы. Корме того что половина гайдов по установке устарела, но все еще лежит на оф. сайте, гайды сообщества противоречат друг-другу, 90% из них не работает, а про некоторые дистрибутивы можете просто забыть, там они работать просто не будут.

2) Оно все работает as is и хрен ты посмотришь как работает родная вьюшка/конторллер "внутри", а доки не сказать чтобы хорошо описаны, комьюнити слабенькое, многие вещи сделаны спорно, а поправить или что-то подкрутить дело неблагодарное.

3) Теперь про самое интересное - скорость работы. Так вот, вся это мутотень про память и прочие плюшки на нормальном сервере не ощущается вообще, то есть переходя определенный предел мощности/вооруженности сервера скорость практически сравнялась с нативом (использовался ларавел и Уии на том же сервере, по замерам - плюс-минус то же по скорости, и чуть больше по памяти (центос, 64гб оперативы, 4 проца, нжинкс, пхп 7.2). Короче выгода была на ветке пхп 5.+, сейчас его актуальность практически равна нулю.

4) В моем случае по приходу сервер регулярно падал при "серьезной" нагрузке (20-30рпс), в чем я изначально предположил вину старых модулей фалкона, но по факту оказалось что 99% нагрузки вносили ожидания запросов к бд, некоторые из которых были по 7-15 минут, а некоторые куски кода создавали по 80+ запросов с 1 страницы, просто дозапрашивая какие-то данные для вьюшки в цикле. Предыдущий "кудесник" кормил руководство отмазками типа - "мало памяти, железо слабое, все плохо, а то бы летало...". "Магия плохого железа" закончилась после оптимизации запросов и доведения самых тяжелых до 0,5 секунды, а так же выборки всех данных в 1-2 запроса с нормальными джоинами.

5) Основной вопрос всегда сводится к жадности - взять что-то побыстрее из софта, сэкономив на хостинге/оборудовании. И оно всегда не работает так, по ряду факторов, которые достаточно очевидны.

Во первых надо задать ангриди флаг, во вторых если нужно все - используйте preg_match_all
https://regex101.com/r/XSYjmy/2

Непреложная истина: Все что находится на/приходит с клиента может и будет изменено с целью взлома/вреда.

Защищать что-либо на фронтэнде абсолютно нет смысла, все проверки делаются на сервере.

Если открыть консоль браузера и в ручную изменить код инпута, к примеру на value=2222
То и POST спокойно отправит это значение.

Ваша задача проверить имеет ли клиент право на изменение объекта с данным значением. Остальное не особо важно, даже если он подставил это значение руками.

ravshan selimov,

isAdmin из состояния редукс

авторизацию проверяю на сервере,

Хранить состояние пользователя в сессии, а не в редуксе, хотя дублировать в рдукс можно. При каждом запросе проверять сессию на текущее состояние залогиненного юзера, проверять имеет ли он право обращаться к нужному контроллеру/скрипту. Для более замороченного входа можно еще какой-то ключ прикрепить к админке, например /admin?key=666 и проверять наличие этого ключа, иначе посылать на 404.

С сайта вы тяните урл картинки из img src, в котором, кроме собственно названия картинки, есть путь (папка) до нее, и вы пытаетесь записать файл по пути, которого у вас на сервере нет. Соответственно будет ошибка.