Aleksei Podgaev

Мы используем SonarQube для подобного рода анализа кода, заодно и покрытие тестами контролируем и возможные проблемы в безопасности: https://www.sonarqube.org/

На свете не существует библиотеки компонентов, даже платной, которая бы удовлетворяла всем потребностям всех разработчиков. Всегда приходится допиливать. Если вы хотите создать крупный проект не написав ни строчки кода и не потратив ни рубля - вы не по адресу.

По моему опыту, чем проще изначальная библиотека, тем легче её модифицировать/допиливать до необходимого функционала. Поэтому я бы предложил связку Angular+Bootstrap. Для хитрых UI компонентов также хорошо подходит React, но к нему нужен ещё зоопарк библиотек для управления состоянием, кэширования AJAX запросов и всего остального.

Сами запросы проще всего реализовать через curl. Как именно вы будете при этом прокидывать параметры со своей формы к серверу - вам решать. Нет ничего сложного в том, чтобы переименовать параметры при обработке на сервере. С другой стороны, если страницу с формой тоже делаете вы или член вашей команды, почему бы не договориться о более удобном именовании полей формы?

Я переехал в Германию и мне уже было за тридцать. Правда опыта было, конечно, больше. Но тут не смотрят особенно на возраст - главное умения и язык. Минимум английский. С немецким и английским будет ещё проще - больше вакансий.

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

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

Страница с блоками хранится в статике или вытягивается из БД?
Если в статике, то да, без cron-а не обойтись. Если же в БД, то от этого и надо плясать. Если страница генерируется динамически, то код сортировки блоков нужно запускать при генерации страницы, а не по расписанию.
Если же блоки должны меняться местами прямо в браузере пользователя, если он, скажем, долго держит открытой страницу (фильм с неё смотрит или ещё что), то тут уже нужно задействовать клиентский javascript.

Из того, что не упомянули явно, можно ещё упомянуть хорошее понимание работы HTTP протокола (заголовки, POST/GET и пр.) ну и по возможности другие полезные протоколы: POP/SMTP например. Это особенно важно для работы со сторонними API, что сейчас в тренде. Ну и cURL обязательно прикрутите к PHP-сборке и попробуйте - на мой взгляд самый удобный инструмент для общения со сторонними ресурсами.

Если не хочется показывать алгоритм расчёта, то, конечно, только вариант 2. Даже если js-файл с алгоритмом как-то минифицировать, всё равно найдётся умелец, который его "дизассемблирует".
Во втором варианте я не совсем понял, что понимается по "оперативной памятью", но полагаю, что проще всего все необходимые для расчётов данные хранить в сессии на сервере (см. $_SESSION) - так меньше данных придётся передавать от клиента к серверу, а значит и скорость расчёта несколько увеличится. Если какие-то промежуточные данные необходимы клиенту, то можно сохранять их либо в куках, как подсказал автор выше, либо в LocalStorage в DOM, либо, если вы используете jQuery, то в дополнительных атрибутах тегов тех полей, которым эти данные нужны. Посмотрите в сторону функционала jQuery.data(). ;)

Согласен с предыдущим ответом. json_encode/json_decode не меняют структуру данных. Так что нужно написать функцию php (или в БД), которая будет выдавать соответствующим образом структурированный результат.
В примере, указанном тобой, как раз в качестве ответа предлагают подобную функцию. Лично мне тот ответ не нравится, т.к. там прямо в коде прошита структура данных с ключами. Стоит формату чуть-чуть поменяться - всё полетит, придётся всю функцию переписывать - это не очень хороший подход.
Твоя структура в этом плане попроще - обычное дерево. Если никто раньше не ответит, попробую вечерком набросать рекурсивную функцию для обхода этого дерева. Уже раз десять подобные функции писал. В том числе и когда в вузе учился. ;)

А есть возможность заставить указывать вызывающую страницу в качестве параметра?
Т.е., например, можно выдавать каждому, кто хочет открывать вашу страницу собственный идентификатор, и пусть все открывают страницу со своим идентификатором:
iframe.php?referer=user1

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

Если мы говорим действительно о провинции, то там нет такого понятия как php-программист. Специалист подобного профиля скорее является web-разработчиком и помимо php обычно знает ещё не менее одного-двух серверных языков, html/css/javascript и всё остальное, что нужно для полноценной разработки сайтов.
Я работал в Хабаровске в разные годы на Perl, Pyton, php, C#.Net, кроме того делал и обычные программы на C#, потом понял, что дальше расти там некуда и уехал в Германию (правда перед этим два года язык учил). Здесь уже освоил конкретно Javascript (ранее знания, конечно были, но относительно поверхностные) и создание мобильных приложений. В общем, получил, что хотел. :)