Нет! Таким образом либо в sizeCont, но скорее всего, как вам ответили ниже, изображение запрашивается уже с размерами 60х60. Т.е. надо посмотреть пример запроса к серверу.
Еще момент! Делать вывод изображений таким образом ОЧЕНЬ небезопасно. В одном из своих ответов на тостере я уже расписывал возможные последствия.
Vitsliputsli, в коде не использовались модели, точнее где то они использовались, где-то был древнейший legacy и SQL запросы на вставку были чуть ли не во View. Таким образом это оказалось простейшим решением и оно работало. Когда добавляли репликацию серверов код править не пришлось, только поправили конфиги MySQL.
Если БД MySQL можно у autoincrement полей последний разряд отдать под идентификатор сервера, или два.
Гуглить по:
auto_increment_increment
auto_increment_offset
Мы таким образом делали балансировку при master-master репликации. Попутно еще шла репликация на slave сервера.
Младший разряд всегда был равен ID сервера.
Хотя сейчас я бы использовал uuid.
Ну в Yii2 так конфиги собираются перед инициализацией Appllication, так что всё тут нормально. Только не include, а require, и без всяких require_once!
Ну а дальше уже autoloader. Хоть свой, хоть PSR.
Кстати! Proposing a Standards Recommendation - Предлагаемые рекомендации стандартов. Не обязательные!!! Но с ними проще, да.
UPD!
Посмотрел внимательней, нихрена тут не нормально! index0h прав на все 1000%!
Обычно такие вещи решаются следующим образом:
1. Загружается картинка-оргинал, впринципе любого размера в папку недоступную из web.
2. Nginx/Apache настраивается на try_files и если в кеше нет картинки, то передает управление php скрипту, который из оригинала (конских размеров) делает нужный размер и кладет в кеш. В дальнейшем картинки отдаются из кеша.
Медленно загружается только в первый раз, поскольку картинки конских размеров. Есть какое то разумное объяснение, для чего они в таком размере? Картинка с салатом 4000х4000 размером 6.5 Мб.
Алексей, попробуйте, но перед этим сделайте резервные копии того, что есть. Если бы сделали бэкап перед установкой плагина - откатили бы до него и всё.
Владимир Хаттер, ну начнем с того, что там нигде нет ни разу слова "шпатлевка"
Идем дальше. По идее при расчете погонные метры делятся на какое то количество секций. Каждая секция обсчитывается по составляющим (к примеру только то краски на столб, столько то на каркас причем в зависимости от его размера, столбов один или добавляется еще один столб для крайней секции, или еще какое условие). Таким же образом рассчитывается расход на ворота или калитку. После все эти значения суммируются. Нормативы эти скорее всего забиты во внутренних справочниках.
Возможно всё намного проще, но мне видится именно так.
Считать от высоты столба и длины профиля наверное тоже не совсем корректно! Столб заглубляется в землю и окрашена будет только его часть. Так что скорее всего мое первое предположение верно, т.е. считается (кол-во столбов * коэфициент) + (погонаж профиля * коэфициент) = ИТОГ
Попробовал калькулятор на сайте - так и есть! Столбы считаются с коэфициентом зависящим от высоты. Ворота изменяют кол-во погонажа каркаса. ГРУНТОВКА а не ШПАТЛЕВКА появляется в зависимости от выбранного типа окрашивания!
И да, нотайсы сыпятся если перейти по zoomurz.by/admin/, на основной странице нотайсы вроде не сыпятся!
Еще! Сделайте принудительный редирект http -> https, сертификат у вас то установлен!
На хостинге скорее всего просто включили вывод ошибок (или обновили PHP и в конфиге по умолчанию E_ALL) вот и перестало работать.
Варианты исправления:
1. Править код и проверять ключи массивов на существование, тогда нотайсы исчезнут, но скорее всего вылезут дальше по коду (по хорошему надо писать так, чтоб их небыло в принципе!)
2. Отключить вывод ошибок (заработает всё с вероятностью 99%, но код лучше всё же поправить!)
NikSIk31, "закладка" в коде делающая его неработоспособным спустя какое то время или после какой то даты. Не очень действенно в интерпретируемых языках программирования, но если обфусцировать код, то пойдет. К примеру делаем демку какого-то скрипта, ожидаем возможный "кидок" по оплате (лучше конечно сразу с таким не связываться, но ситуации бывают разные) - в коде делаем "закладку" типа if (date > dateX) {alert('Где деньги, Зин?'; exit(0);} DateX в данном случае дата, которая означает, что наш код используется, а вот бабосы нам так и не отгрузили. Код схематичен, да и другой разработчик думаю быстро устранит эту проблему, но думаю он тоже задумается, для чего это тут. Думаю смысл понятен.
Антон Вебсайтовский, начинали делать на Kohana 3.2 по моему, потом появились namespace и пришлось переделывать массу кода, но тут не особо Kohana виной. Следом поддержка коханы была прекращена и уперлись в то, что все нововведения пришлось добавлять руками, по сути сами опять делали свой фреймворк, из-за чего опять начались "терки" внутри команды. Скорее всего вины именно фреймворка тут нет, но ввиду прекратившейся поддержки нагородили опять кучу говнокода и проект был благополучно слит.
После, спустя несколько лет, уже другим составом команда пыталась переписать те же сервисы на Yii2, но ввиду низкой квалификации и сработанности нагородили по принципу "в лоб", т.е. без сервисного слоя и прочих радостей. Делали по принципу, как и здесь, в примере кода и поначалу это всё прекрасно работало. В итоге кучи дублирования кода и т.д. Начали на "горячую" это рефакторить с использованием DDD, но возникла другая проблема - внешне и функционально то ничего не меняется, и вот скорее всего финансирование этого скоро свернут, либо...
Как итог, скажу, что быстрое, сиюминутное и рабочее решение в итоге может в итоге потянуть за собой кучу проблем. К примеру сделали мы CRUD прямо из контроллера и всё работает. Завтра добавили API и там это же продублировали, послезавтра добавили API v2 и что-то продублировали, что-то дописали, потом у нас изменилась чуть-чуть бизнес логика, и где-то мы забыли поправить код. Всё, приплыли. Началось расхождение результатов. Разработчики копит баги в трекере разбираясь с расхождениями данных и т.д. А потрать мы немного больше времени на проектирование изначально и вынеся эти действия в сервисный слой (это простейший пример само собой) мы бы избежали как минимум этой проблемы. Продолжать можно очень долго, меня и так унесло уже от сути основного вопроса.
То же касаемо и имен\форматов полей в БД. Пока не составили гайд по всем возможным вариантам - каждый городил что хотел и как ему было удобно на тот момент. В итоге начались конфликты типов на связанных таблицах, проблеммы с приведениями типов и т.д. Простейший пример - метки времени. Сошлись на именованиях типа created_at, updated_at, published_at и т.д. и типе данных TIMESTAMP. ID записей в БД - отказались от автоинкрементных значений в пользу UUID. Сначала было неудобно и непривычно ,но привыкли и втянулись по итогу. Для примера - когда ввели репликации серверов (а использовался MySQL) то чтоб исключить пересечение ID на уровне настроек MySQL младший разряд стал идентификатором сервера (параметры auto-increment-increment и
auto-increment-offset) и всё было замечательно, но вот для связанных данных (к примеру медиа к публикации и т.д.) приходилось заводить виртуальные ID (поскольку мы не знали ID который будет присвоен основной записи) и производить пост-обработку. Потом Сделали вариант с черновиками, т.е. при нажатии создать создавалась пустая запись со статусом STATUS_DRAFT и происходил редирект на её же редактирование. Сборщик мусора периодически удалял из таблиц записи у которых created_at == updated_at и created_at < (time() - сутки), т.е. черновики, которые таки не довели до ума. UUID решил эту проблему (хотя от черновиков мы в итоге так и не отказались, удобная оказалась штука!).
Что то меня понесло... Но надеюсь мой ответ в целом окажется полезен и убережет от ошибок в будущем.
Все зашибись, только отчего $post_id тоже в bindValue не добавить? А то там можно ой как много чего наделать.
Ну и при желании, откинув верхнеее замечание, тем же curl`ом я загажу БД буквально минуты за 3 так, что проще будет таблицу дропать, чем чистить. Ну а если спам-бот унюхает эту форму, то еще хуже. CSRT-token чтоль прикрутить сюда надо.
По сути вопроса в гугл: нормальные формы, нормализация, денормализация.
2й момент - ORM, как и AR в Yii2 (к примеру) снимает принцип единой ответственности с "модели" которая выдается за таковую что в кохане, что в Yii2. Тут, как мне кажется, правильней было бы Repository и UoW (UnitOfWork). В совокупности с нормализацией БД (а так хранить данные - это моветон) и кешированием убрало бы "дрочку" БД.
Ну а если реально:
1. Забудь про кохану. Она не то, что мертва, она мертворожденная лет так почти 10 назад, но хрен с ним.
2. Структура БД. Нормализация. Что есть сущность. Что первично. Что связано с ней. Что из этого обязательно.
3. Экшены: простейший CRUD (index(), create(), update($id), delete($id), view($id)) даст понимание что и как делать с ID.
4. Ну и для дальнейшего развития - (мое личное мнение) НИКОГДА не использовать PRIMARY_KEY как integer AUTO_INCREMENT, Uuid наше всё!
5. Имена полей и атрибутов. $akciititle или $akciiTitle - что удобней читать? Названия транслитом - ну есть же гуглопереводчик. Завтра вы будете писать код не в одного, а командой и будет у одного $akttiXXX у второго $akciiXXX у третьего $akciyaXXX.
Вариант 1:
$rules = [
['attributeToValidate','string','when' => function() {return $this->validationCheckBoxAttribute == false}]
]; https://www.yiiframework.com/doc/api/2.0/yii-valid...
Вариант 2: Сценарии
Вариант 3: Ансетить поля для валидации в beforeValidate()
Вариант 4: .......
Одним словом - вариантов масса. Как по мне - то 1й самый простой. Его же можно через whenClient применять для клиентской стороны.
Еще момент! Делать вывод изображений таким образом ОЧЕНЬ небезопасно. В одном из своих ответов на тостере я уже расписывал возможные последствия.