FanatPHP

НЕ СЛЕДУЕТ вообще заниматься такими вещами, как включить файл в функции. кроме совсем редких специальных случаев. Файл надо прочитать отдельно, и потом передать его содержимое в функцию в качестве параметра.

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

поэтому данный код переписать так

class ClassName 
{
    protected $config;
    public function __construct($config)
    {
        $this->config = $config;
    }
    public function FunctionName()
    {
    }
}
$config = require __DIR__."../config.php";
$obj = new ClassName($config);
$obj->FunctionName();

Оставь всё как есть, ничего руками не трогай.

Я остановлюсь на одном аспекте этого кода, но совершенно анекдотическом.

Такое ощущение что все пэхапешники практически поголовно - потомки контрабандистов. Ну или мешочников, которые в китае покупают сумку за три копейки, везут в Хабаровск, вешают ценник "Луй Витон" и продают за пять. И даже если купят Настоящий Louis Vuitton, то все равно сдерут бирку и нацарапают шариковой ручкой другую. И это совершенно не укладывается в голове.

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

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

Этот твой код выглядит так, как будто тебя кто-то заставил выучить правило - "любой блок кода надо завернуть в try catch!" Причём доходит до анекдота - если уж совсем не знаешь, что делать внутри catch... то тупо делаешь throw. Зачем тогда вообще делать try? "А шоб було!".

Вот взять самую первую проверку, ! file_exists($fileName). Если её выкинуть, то при попытке открыть несуществующий файл ты получишь подробное сообщение - КАКОЙ файл пытаешься открыть, и ПОЧЕМУ конкретно это не получилось. То есть сообщение об ошибке УЖЕ есть, и в миллион раз информативнее. И какой смысл повсюду втыкать file_exists - ЗАГАДКА. Загадка почище тайны египетских пирамид. Там хотя бы понятно, зачем их городили.

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

Самое забавное, что все писатели, которые старательно выводят "Error saving language", совершенно не представляют себе - для кого они это делают. Для пользователя? Если он даже и увидит это сообщение (за что надо отдельно по рукам бить), то он и так знает, что проблема с сохранением языка - он этим и занимался. Не говоря уже про 'Unable to open file'. Какое филе? Почему унабле? Что с этим делать?
Для программиста? Вместо подробного системного сообщения об ошибке читать эти загадки, серьёзно?

В общем выкидывай все эти бессмысленные проверки. Ты работаешь с фреймворком, а не клепаешь на коленке. фреймворк писали не дураки, он прекрасно обработает все ошибки сам.

И забудь ради бога это дурацкое правило, оборачивать любой блок кода в трай кетч. Вместо него запомни другое:

Надо обязательно различать пользовательские и системные сообщения об ошибках:

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

Не принимай резкость этого текста персонально - просто это реально проблема с писателями на пэхапе в целом.

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

То есть ошибки, после которых продолжение работы бесполезно, вообще никак не отлавливать не надо. Ларавель сама за тебя все отловит и напишет. Потому что в ней уже все оформлено, и отлов и обработка. И не надо туда лезть руками.

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

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

В целом же стараться "отлавливать и оформлять" как можно меньше. И стараться понимать, что ты работаешь с современным фреймворком, в котором все нужное уже есть, а не по-старинке говнякаешь на коленке

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

Может
Ты уже задавал этот вопрос

если отнимать не больше чем есть, то
update t set a = a - FLOOR( 1 + RAND( ) * a );

В цикле.
Все операции с массивами всегда производятся в цикле.
самым удобным циклом в РНР является foreach

В общем в качестве ответа на этот малопонятный вопрос можно выдать только общие рекомендации

Во-первых, транзакции в БД не имеют вообще никакого отношения к транзакциям в бухгалтерии.
И к увеличениям балансов.
Транзакция в БД несет очень простую функцию: гарантировать что все запросы внутри транзакции завершились успешно. то есть чтобы не было неконсистентных данных - в одну строку добавились данные, а во вторую нет. Поэтому транзакция в случае ошибки откатывает все изщменения, которые ты успел сделать.

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

Но при этом тебе и блокировки тоже не нужны, поскольку заниматься такой ерундой, как "прочитать, добавить и записать" в принципе не нужно, поскольку можно совершить атомарную операцию - СРАЗУ в запросе и прибавить нужную сумму, без придварительного чтения.

Но самое главное - тебе сначала надо решить, каким образом вообще ведется бухгалтерия - добавлением строк, или обновлением строк.

В общем, к "объединение кучи баз mysql в одну, под управлением одной админки" твои проблемы не имеют никакого отношения.

Базы данных все примерно одинаковые, одним не хватает таблиц, другим столбцов. Это приходится добавлять(но это пол беды).

В современном мире для этого служат миграции.

обновление админки, которая функционирует на php. Переписывать запросы в базу, исправлять ошибки, менять название функций, добавлять/удалять переменные и т.д.

В современном мире это целая отрасль, которая в первую очередь базируется на системе контроля версий. Если в твоём агентстве она не используется, то надо бежать оттуда.
Потому что вредрить её у тебя вряд ли получится, а работать с распределённой кодовой базой без CVS - это даже не каменный век, а какие-то амебы в первичном бульоне.

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

Начни пользоваться своими "блогом" и "соц-сетью". Сразу поймешь что пользоваться ими невозможно.
И начинай допиливать потихоньку.

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

Вопрос, как всегда, совсем не о том.

Код этих двух "классов управления записями" по сути ведь не отличается друг от друга. Отличается только формат этих записей, в котором класс выдаёт результат работы - либо массив, либо объект.

То есть вопрос на самом деле - в каком формате работать с книгами в коде - в виде массивов или объектов, а не как ими управлять.

И ответ на него очевиден - поскольку в объект можно вкрячить кучу функционала, например метод validateISBN(), то однозначно работать с объектами удобнее.

Как через ajax получить данные из php файла?

Наверное, их надо послать?

Если у тебя выборка из бызы выедает 50 метров, ты что-то делаешь ОЧЕНЬ неправильно.
Нормальному пхп скрипту выводящему обычную хтмл страничку нужно край 8 метров.

Уже давно написал бы на Ларе, чем ходить искать "без фреймворков".

Фреймворкофобия - это болезнь, надо лечиться.