dev400

Ведь в любом случае мы получаем глобальное состояние

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

Какой смысл использовать именно singleton?

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

В PHP, где не не особо популярна идея многопоточного программирования, и процветает "умирающая" модель выполнения, в сингелтонах вообще нет смысла. И используют их потому что... внимание... хотят иметь глобальный доступ к различной фигне, в том числе организация глобального состояния.

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

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

ну а на практике вы пытаетесь решить "Как быть, если в любом месте в коде можно вызвать DROP TABLE users"
да никак не быть, просто думать головой. это несложно.

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

Не забывайте, что в фреймворках это все сделано с одним расчетом - покрыть 95% возможных юзкейсов. А в связи с этим реализация чуточку сложнее. Так же не стоит забывать, что все это "должно" работать на php5.4+, а, например password api появился только в 5.5, а хэширование пароля это целая наука.

Давайте разложим задачу на под задачи:

Нам нужно проверить введенные пользователем данных. Это может быть пара идентификатор + какой-то секретный ключь (email + пароль если проще), а может это просто секретный ключ (токен), или JWT токен... словом вариантов тут много, но нам пока нужна пара старых добрых email + пароль.

Для этого в PHP есть весьма простая в использовании апишка для работы с паролями: password api. Используйте только ее (или что-то что ее под копотом использует) ибо это самый безопасный и надежный способ работы с паролями в PHP. Обязательно прочитайте этот раздел документации.

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

После того как мы убедились что пользователь не выдает себя за другого, мы можем создать сессию. В самом простом случае мы просто создаем сессию с ID юзера и... собственно все. идентификатор сессии будет записан в http-only куку и все здорово. Правда при работе с сессиями в PHP нужно помнить про CSRF атаки, от которых нужно защищаться (что умеют практически все фреймворки из коробки).

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

p.s. поскольку этот вопрос весьма щепетильный, и ля того что бы сделать все это "безопасным" нужно порядком опыта, я рекомендую вам разобраться с фреймворками или готовыми популярными библиотеками.

В данном случае понятие "лучше" неприменимо - это две равноценных альтернативы со своими плюсами и минусами. Выбирайте любую, недовольные будут в любом случае :)

Так там вроде ничего сложного, можно самому пару методов написать для упрощения работы:
https://developers.google.com/drive/v3/web/quickst...
https://tech.yandex.ru/disk/rest/

регулярка из статьи на phpinfo.su
в чем вопрос у тебя?

К примеру так$('.selector').append("<input type='text'/>");

Подробнее про append тут

Почитайте, optimization.guide и вот вам немного теории:

Кешировать можно:

• целиком всю страницу (для каждой страницы своя запись в кеше)
  
• отдельные части сайта
  

Кешировать можно в файлах:

• генераруя готового html
  
• генерируя html+php, так работают smarty и прочие шаблонизаторы собирая множество шаблонов в один
  
• в виде бинарного содержимого, сюда и готовый html и готовые значения вычислений и прочее
  
• в виде сериализованного массива с чем угодно, от предыдущего пункта отличается только форматом хранения
  

Кешировать можно в базе:

• в mysql/postgresql и прочих SQL - будет храниться на диске и горячие данные в памяти
  
• в mysql/postgresql и прочих SQL в in-memory таблицах - будет храниться в оперативке, но без дополнительных усилий кеш пропадёт при рестарте сервера
  
• в in-memory базах данных, часто это memcache, redis и прочее - опять таки выключили сервер - данные пропали
  
• в in-memory базах данных с сохранением на диск, это Tarantool, memcachedb и прочие если там заявлена такая функциональность
  

Так же можно:

• кешировать всё кроме вставок динамики
  
• кешировать куски вставляя их в динамику
  

Это два противоположных подхода которые при особом желании можно смешивать в рамках одного проекта.

Обновлять кеш можно:

• при каждом запросе проверяя что старый кеш устарел
  
• предкеширование - отдельным кроном/демоном/сервисом генерировать кеш раз в N минут
  
• по мере изменения данных сбрасывать кеш и следующий запрос сгенерирует новый
  
• по мере изменения данных сбрасывать кеш путём генерации сразу нового и замены старого на новый
  

Кеш можно хранить:

• на том же сервере что и сайт - нет задержек в сети, но зато ресурсы теже, CPU, диск, оперативная память
  
• на внешнем сервере - задержки в сети, зато ресурсы отдельно
  

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

Если используете CMS/CMF - посмотрите готовые плагины для кеширования. Если у вас не sharing-хостинг с мини-сайтом - озаботтесь профилированием (xhproof) и мониторингом, это поможет понять где и что кешировать.

Так же стоит рассмотреть кэширование байт-кода:

• OpCache
  
• APC
  
• XCache
  

Стоит прочитать вот эту статью:
Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache https://habrahabr.ru/post/264775/

Так же стоит:

• увеличить буферы в MySQL (если памяти много)
  
• потюнить другие системы, например поставить nginx вместо apache, раздавать статику с другого хоста
  
• и конечно же - посмотреть как долго работают SQL запросы и по возможности их облегчить
  

Кеширование в MySQL с использованием HandlerSocket:

• данные хранятся в MySQL innodb базе, а значит чтение и запись можно делать как по старинке через SQL так и через HandlerSocket
  
• можно сделать любое количество колонок, лишь бы это позволял MySQL
  
• быстрая вставка
  
• быстрая выборка
  
• бинарный протокол передачи данных
  
• есть несколько библиотек для PHP, как относительно новых так и старых
  
• в Percona Server (форк MySQL) HandlerSocket.so есть в поставке по умолчанию, разве что нужно включить
  
• в MySQL необходимо собрать HandlerSocket самостоятельно и включить в MySQL
  

Можно почитать вот тут:

• То, что вы хотели знать о HandlerSocket, но не смогли нагуглить, Сергей Аверин - https://www.youtube.com/watch?v=qHqdhJ9ziik
  
• Gentoo Overlay с HandlerSocket, давно не обновлял но вроде работает - https://github.com/mantyr/overlay-gentoo-flower
  
• HS кеш, тоже давно не обновлялся, но как пример сойдёт - https://github.com/mantyr/php-hscache
  
• PHP Extension для HandlerSocket, не содержит последних коммитов, но зато, наверное, единственое место где есть точное описание всех методов и входящих параметров, https://github.com/mantyr/php-ext-handlersocketi
  

Нормально

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

- Сделать как на вашем примере, т.е. через SVG
- Сделать видеоролик, вставить через тег «video»
Привязать к скролу и к ховеру.

Это Canvas

Долго и муторно наверное их было рисовать... подумайте 100 раз - надо ли Вам это...

К тому же я перешел на сайт и не сразу даже догадался, что нужно навести курсор на этих зверей и человечков для анимации )

В Вашем случае возможно будет проще сделать анимированные gif-ки и вставлять их на страницу при прокрутке?

значит либо в хедере, либо в футере стоит компонент, который не находит либо раздел либо элемент инфоблока, а в настройках у него стоит "SET_STATUS_404" => "Y", . Элемент/раздел не найден - ставит заголовок 404.