myspace

Обменивайтесь токеном через куки. С сервера - обновляйте, а с клиента сам придет.

только если писать свои гетер/сетер или эмулировать их через __callStatic.
так как с __set/__get работать со статикой не выйдет.

Никак. Есть предложение, но так и не реализовано https://wiki.php.net/rfc/static-classes
Сделайте свой getter

public static function getVar () {
  return self::$var;
}

- Представление о MVC имею. Раньше писал пару проектов на CodeIgniter, но на нём на мой взгляд мало что есть из коробки, и много времени уходит на разработку.

С тех пор изобрели Composer, при должном желании прикручивается он и к CI в том числе :)

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

На русском - CodeIgniter, на не русском - Laravel, Symfony и другие.

- Хотелось бы большое количество подключаемого функционала из коробки, для экономии времени разработки. Например уже написанная логика авторизации, регистрации, восстановления пароля и разграничения по уровням доступа. Понимаю что всё равно придется немного допиливать под свои нужды, но времени это сэкономило бы кучу.

Composer - решает 99% проблем, практически в любом фреймворке.

- Возможность работы с различными БД из коробки

Пока фреймворков без этой штуки не видел, но есть... Вы не поверите, Composer, что бы сменить/поставить "другой" ORM, если Вам "текущий" чем-то не подошел.

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

То о чем Вы говорите, это: Varnish, Nginx+SSI и т.д. кэширование "из коробки" есть в Symfony (т.к. если его отключить, страницы может генерироваться феерически долго)

- Не тяжелый фреймворк, в котором оптимизирован код, и который не жрёт огромное количество ресурсов на сервере. Если будет поддержка PHP7 - тоже плюс.

По моему, любой современный фреймворк, если уже даже "Битрикс" небеизвестный до этого до этого дошел... некоторые фреймворки вообще скоро будут требовать PHP7, а не только "поддерживать".

- Проект будет ориентировочно крутиться на nginx+php5-fpm. Думаю практически все фреймворки смогут работать в этой среде, но вдруг...

Я пока таких "вдруг" не встречал. Если у админа голова и руки на месте - то никаких "вдруг" быть не должно. А вообще, у PHP версии 5.х, есть как минимум 3 основных "ветки", это <5.3, >=5.3 или 5.4+ и т.д., ещё кое-какие отличия были в 5.5 и 5.6, но не такие "разительные", подробности можно почитать в истории версий PHP. По этому, нужно конкретнее указывать версию, например, Laravel требует 5.6+

- Возможность масштабирования. В принципе не обязательно, но возможно однажды будет масштабироваться проект.

Это не возможность фреймворка - а навык программиста/админа.

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

1. Yii2
2. CMS + готовые модули CMS
3. Вы не забыли, что есть... composer?!

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

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

Не за что! Кнопка "Мне нравиться" - сразу под сообщением :D

var form = document.querySelector('form');
var data = new FormData(form);
var req = new XMLHttpRequest();
req.open('POST', 'http://example.com');
req.send(data);

Пример с сериализацией в строку: https://jsfiddle.net/Stalk/v4huwft4/

Я не буду говорить про ООП, читаемость кода или его модифицируемость в будущем.

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

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

p.s. по теме, если параметр, который подставляют в вызов method() будет браться из-вне, например значение одного из параметров в GET, то я бы порекомендовал пропустить эти параметры через специальный метод-фильтр, конвертирующий строки во внутреннее представление (числовые дефайны или ссылки на методы), он же проверяет их валидность... вот это удобство для программиста, когда выделяется отдельная задача в отдельный метод/класс... ООП тут совершенно не требуется, так как нечего наследовать, хотя может быть использовано просто как синтаксический способ объединить код и данные в одном месте.

А в каком месте он работает с глобальными переменными?
Инициализируется из сессии, дальше работает только с локальной копией, полученной в момент инициализации объекта. Соответственно каждый объект может иметь свой набор данных и ни один из них не будет сохранён в сессию.

"csrf из сессии с csrf из базы"
и по какому принципу вы их сверять собираетесь? искать в базе запись с тем же хэшом )))

сверять нужно из сессии и из поля в форме.
< input type="hidden" name="token" value="hfjdhsalkjdfhlaksjd" >

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

Добавлять в базу - это лишнее. Какие параметры? Случайная строка + ip пользователя + user agent пользователя.

учитывая то что по умолчанию в функции render $actionData = [], вы подразумеваете, что это нормально. Нет возможности выбирать, какому параметру оставлять значение по умолчанию, а какому присваивать, поэтому выживаем как можем
upd:
если вас этот факт смущает, сделайте часть параметров передаваемыми через ассоциативный массив.
и будет у вас

function render($actionView, $params = []) {
// понеслось 
 $actionData = (isset($params["actionData"]) && $params["actionData"]) 
 ? $params["actionData"]
: [];
//и тд
}

хрень
вот так надо:

/**
     * Очищает массив от пробелов и слэшей.
     *
     * @param array
     * @return array
     */
    private static function clearData(&$in)
    {
        if ($in && is_array($in)) {
            foreach ($in as $key => $value) {
                if (is_array($value)) {
                    self::clearData($in[$key]);
                } else {
                    $value = trim($value);

                    if (get_magic_quotes_gpc()) {
                        $value = stripslashes($value);
                    }

                    $in[$key] = $value;
                }
            }
        }

        return $in;
    }

т.е. приходимся рекурсивно по POST (и GET и REQUEST кстати тоже надо) и чистим от пробелов и, если у вас версия php с магическими кавычками, то от возможных слэшей.

далее, одна из частых ошибок новичков - обрабатывать данные через htmlspecialchars() или её эквивалент как у тебя. хз где этому учат, вероятно есть какая-то секта, не иначе.

ЗАПОМНИТЕ РАЗ И НАВСЕГДА - htmlspecialchars нужен ТОЛЬКО при выводе данных в шаблон. htmlspecialchars нужен что бы символы, являющиеся частью языка HTML преобразовывать в мнемоники, т.е. в эквиваленты, что бы верстка не поехала, когда в ваших данных встретятся символы <>" и '

в базу надо ВСЕГДА записывать данные как есть - что пришло, то и записываем.

CSS и JS:
К примеру, у вас имеется большое количество (Х штук) css или js файлов, которое вы подключаете на своих страницах посредством тэгов <link> и <src>.
При загрузке страницы, браузер клиента будет отправлять X запросов к вашему серверу, а ваш сервер должен будет ответить на X запросов.
Это:

1. Тормозит загрузку страницы - будете ждать ответа от сервера
   
2. Загружает ваш сервер
   

С помощью сборщиков фронтэнда вы можете "склеить" все файлы в один - main.css и main.js, которые будут отдаваться 2 запросами с сервера. Также, вы сможете минифицировать CSS и JS. Под минификацией подразумевается уменьшение размеров файла на диске. Естественно, более легкий файлы будет быстрее прогружаться + минимальное количество запросов к серверу.

IMG:
К примеру, у вас имеется Х изображений размером 700 Кбайт. Клиенту надо будет загрузить 700 * X Кбайт. Если вы пропустите свои изображения через Gulp, то вы получите изображения с меньшим размером на диске и такого же качества, т.е. клиенту придется прогрузить примерно (500-600) * X Кбайт.

Добрый день.

Собственно, проблема не великая:
01. Делаете (заказываете) договор публичной оферты и к нему делаете 1 лист бумажный. В листе будут указаны реквизиты и основные условия + то, что контрагент присоединяется к договору оферты, который опубликован по адресу (http://....). Всё. По ст. 434 ГК РФ: "Договор в письменной форме может быть заключен путем составления одного документа, подписанного сторонами, а также путем обмена письмами, телеграммами, телексами, телефаксами и иными документами, в том числе электронными документами, передаваемыми по каналам связи, позволяющими достоверно установить, что документ исходит от стороны по договору". Повторюсь: да, ФНС любит "бумажную форму", хотя в суде они проигрывают по этому поводу с треском давно, но всё же, не испытывая судьбу - отправляете копию по факсу (можно даже через онлайн-сервисы), а потом, скажем раз в квартал, направляете письма контрагентам. А они свою копию - Вам.

02. Если подключите агрегатор (мне нравится Z-Payment - но это дело сугубо вкуса и процентов), то он, конечно, вышлет акты Вам. Но контрагентам - нет. Есть аутсорс компании, да. Но это за деньги. Как и бухгалтер, юрист и любой другой специалист. И деньги не больше. Но можно в общем-то 1 раз заказ анализ по своему виду деятельности (например, договор возмездного оказания услуг или, скажем, что дальше от вас, агентский договор) и по форме готовить нужные документы. Онлайн-сервисы уже называли, их не масса, но тоже хватает. Совсем без отчётных документов худо: и перед налоговой не удобно, и самому потом тоже, когда нужно будет дебет с кредетом свести - во многих ООО бухглатера до сих пор слишком дотошны, т.к. дотошны инспекторы ФНС. Впрочем, я просто не люблю представителей этого вида, может - в этом проблема.

03. Но главное, Вам нужно понять, что есть документы, кот. обязательны для налоговой, а есть те, что играют роль во внутреннем обороте между юр. лицами и ИП (или ИП-ИП). ЭЦП для первого вида - нужна только из сертифицированного сервиса со всеми последствиями, а вот для второй группы - уже давно можно организовать документооборот чисто электронный (или с минимальными бумагами - сверками по желанию). Просто у нас предприниматели очень запуганные и для них понятие "аналог собственно ручной подписи" (тот же email) или неквалифицированная подпись - как гром. А на самом деле всё в указанном ФЗ и ГК описано.

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

В целом, у Вас уже есть, что компоновать по ответам. Не буду повторяться.