Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
То есть я предполагаю, что большой размер текста приводит к возникновению ошибки. Я не знаю к какой именно. Но эта ошибка тобой не ловится, а тупо выводится и мешает установке заголовков, т.е. сессионная кука не передаётся в следующий запрос.
Если сессионные переменные теряются, это может означать ситуацию "Headers already set", то есть, где-то происходит неучтённый вывод, какое-то echo-шмэхо. Возможно PHP ругается нотисом или ворнингом. Поэтому оказывается, что кука, а следом и сессия не могут быть установлены!
Смотри внимательно исходный код HTML той страницы, на которую не попадают твои переменные. В браузере вызови контекстное меню и там "View Page Source".
Если переменная содержит JSON (т.е. строку!!!), то надо его сначала преобразовать в структуру:
$x = json_decode($json);
и только потом обращаться к его элементам. Сделай так, потом выведи значение dd($x) чтобы знать где чего.
Ничего непонятно.
"Ежеминутно отрабатывает задача" - ты про консольную команду, которая в расписании Laravel прописана? Если нет, то вот, надо создать консольную команду 
"Как и куда будет правильным прописать фильтры? В middleware?" - какой фильтр, от чего он зависит? Обычно когда говорят о middleware, имеют в виду входящие HTTP запросы, авторизацию доступа, но кажется это не сочетается с предыдущим вопросом. То есть, врядли тебе нужен мидлвар. Просто создай класс или функцию с фильтром и используй его. Назови его "сервисом", если надо как-то назвать. Инжекти его в метод handle своей команды.
public function handle(App\Services\FilterService $filter)
"Может есть примеры реализации подобного?" - с таким мощьным описанием это почти любой проект на Laravel. Так что, нет.
данные переменной $routeName в в файле роутов web.php
Ты начинающий и поэтому не понимаешь как работает существующий роутинг Laravel. Когда узнаешь получше, ты откажешься от идеи переписать его по своему Вместо этого будешь использовать то, что есть. Потому что оно крутое, круче чем ты мог бы сделать сам.
Если хочется сделать "универсальный маршрут", который реагирует на все URL-ы, не описанные в готовых маршрутах, то просто помести в конец web.php такое:
Route::any('(.*)', 'UniversalController@any');
А в методе UniversalController::any работай с объектом request как тебе в голову придёт.
Я честно вам скажу, не могу понять чем лучше отношения от обычных запросов
А кто говорит, что они лучше? Это вещи как бы не взаимоисключающие.
Отношения Eloquent упрощают обращение к свойствам связанного объекта, не вдаваясь в детали реализации. Они бывают очень удобны, особенно если есть более одного уровня вложенности. Что касается дополнительных полей, то можно добыть их все. Я не понимаю ваш код, вижу только что вы не соблюдаете стандарты, поэтому вряд ли можете судить что работает, а что нет. Посмотрите в офф доки, там все отношения пишутся через $this->has* или $this-->belongs* . А у вас что?
Если цель построить эффективный запрос, то пишите на сыром SQL. Если цель написать код в стандартах Laravel, чтобы вашим преемникам будет удобно поддерживать его, используйте методы Eloquent по максимуму. Даже в ущерб супер-эффективности.
А я не согласен с предыдущим оратором насчёт EAV
Всё имеет свою цену. Универсальность конфликтует с простотой и производительность. EAV хорош когда набор свойств нельзя предсказать заранее. В данном случае, когда сайт работает с одним и тем же "товаром" - недвижимостью, я не вижу необходимость повышенной сложности запросов.
Я предлагаю делать просто таблицу объектов недвижимости (builds?) с большим количеством колонок-свойств.
@Serezha разложи задачу на под-задачи. Тебе понадобится маршрут, экшен в контроллере и какой-то запрос Eloquent. Какой именно момент тебе непонятен?
Если все сразу, то наверное надо начать с учебников.
Я вижу здесь только один более-менее хитрый момент — это маршрут. Попробуй сделать его сначала через замыкание, пусть просто выдаёт текст Hello $username и больше ничего.
Ты вообще знаешь для чего папка vendor?
У тебя в репе должны быть файлы composer.json и composer.lock. Они однозначно указывают какие пакеты должны быть установлены по команде composer install. А значит просто незачем добавлять в репу стопицот миллионов чужих файлов. Твоя репа для твоих файлов only.
Ты так и не сказал какая была цель. А мог бы получить подсказку.
Например: хотим вывести все поля таблицы Users(id, name, age, salary) + количество записей, совпадающих с текущим пользователем по возрасту. Или давай максимальную зарплату людей того же возраста. Похоже на твою невозможную группировку, да?
Можно решить с под-запросом:
SELECT
u.id,
u.name,
u.age,
(SELECT MAX(salary) FROM users WHERE age = u.age) AS max_salary
FROM
users AS uТак должно работать. Этот запрос можно ещё переписать через JOIN, суть не поменяется.
Вот именно тут мне придётся часть функционала выборки из sql перенести на php, так как на sql я не могу выбрать всё, сортируя по двум полям. Придётся выбрать всё, а на пхп подсчитать схожие записи.
ой *ля-а-а-а-а! привыкнешь к такому и всё, ты умер как разработчик.
Отменить ONLY_FULL_GROUP_BY или использовать ANY_VALUE() ? Ну если тебя устраивает такое "решение"...
Сервер MySQL ты победишь, но логику нет Мне кажется ты занимаешься самообманом. Однажды ты увидишь, что получил не то, что хотел.
It really should be called SURPRISE_ME()
Я согласен с тем что бывает удобнее несколько запросов чем один. Но данный пример я не знаю как переписать ни в один, ни в несколько запросов чтобы не было очевидного бестолкового оверхеда. PHP не должен брать на себя функцию сервера БД.
Продублировал вопрос на laracast в предельно упрощённом виде, может там подскажут.
То, что данный отчёт получается сложным не означает, что нужно рефакторить всё к чёртовой бабушке чтобы оно гладко описывалось через has
Здесь загвоздка скорее в ограниченных возможностях Eloquent, а не в плохой модели. Eloquent это надстройка над или пре-компилятор SQL. Он по определению не может дать больше, чем даёт SQL. Хотя некоторые типовые действия выглядят в нём удобно.
Всё же я надеюсь, что удастся найти хороший перевод.
Сразу вопрос: это реалезуемо в Laravel?
Laravel может работать со всеми вариантами отношений, которые ты перечислил. Так что да. Если ты можешь это выразить в терминах реляционной базы, то это реализуемо на Laravel.
Т.е. полиморфные связи и одновременно один ко одному и один ко многим.
По-моему это чушь. Надо переосмыслить какие реально нужны связи.
Мне кажется ты упустил такой момент, что есть наименование (или тип) товара и есть единица хранения товара - штука, упаковка и т.п. Единиц одного наименования может быть много и они могут быть разложены по ячейкам. Не наименование товара раскладывается, а экземпляр.
Видимо, отношение экземпляра к ячейке один-к-одному. Возможно полиморфиный, я не уверен. Я бы пытался сделать просто с минимальным набором сущностей, и только когда не получается просто, тогда усложнять.
Наименование товара к экземплярам товара относится как один-ко-многим.
Тип расходник/оборудование можно описать булевым или enum полем в таблице наименований. Свойства товара разместить в одной "широкой" таблице с nullable полями на все случаи жизни. Я не вижу здесь жёсткого требования заводить по отдельной таблице на каждую разновидность товара. Можно да, но можно и нет.
То есть что бы все поля вывести, мне их нужно все заталкать в groupBy.
Нет. Если ты все поля затолкаешь в group by, то группировка потеряет смысл. Это правило абсолютно логично, надо только его понять и принять.
Есть хороший пример: допустим у нас есть таблица людей с именами, возрастом и размером зарплаты. Допустим мы группируем по возрасту, что мы можем получить на выходе кроме возраста?
Имя - нет! Потому что может быть несколько человек одного возраста, непонятно какое имя брать из этих нескольких.
Зарплата - нет! По той же причине.
НО мы можем получить максимальную или среднюю зарплату по возрасту. То есть применить агрегатную функцию к полям, которые НЕ входят в список группировки. Понимаешь?
Допустим ты "выкрутишься" как собирался здесь, группируя и по возрасту, и по имени, и по зарплате. Что получишь на выходе? Да просто исходную таблицу
Итак, что ты хочешь получить, своими словами, и почему взялся группировать?
Запрос на сыром SQL работает как надо. Не хочется в Laravel писать всё через DB::RAW() это как-то неэстетично.
Колдунство с
JOIN xxx ON id = SELECT MIN(id) FROM xxx WHERE fk_id = yyy.id
понадобилось так как надо прицепить первую из нескольких подходящих записей.
Тому гуру Eloquent кто осилит перевод, от меня будет огромный респект!
Помогите выразить на Query Builder без RAW, но через joinSub или подобный механизм вот такой непростой запрос:
SELECT
SUM(w.weight) AS weight
FROM container AS c
JOIN weight AS w ON w.id = ( -- First weight
SELECT MIN(id) FROM weight WHERE container_id = c.id
)
LEFT JOIN container_run AS cr ON cr.id = ( -- First link to process if any
SELECT MIN(id) FROM container_run WHERE container_id = c.id
)
WHERE
cr.type = 1 OR cr.type IS NULLВидимо тем 5 человекам, кто читает, описанная проблема не близка.
Лично я не понял что тебе мешает прочитать текст предупреждения и сделать что написано. Оно ведь написано.
Пишу свой кастомный экшен под Laravel Nova. Это экспорт по шаблону в PDF. Понадобилось узнать по какому занчению отфильтрованы записи чтобы отобразить это значение в документе. Кто-нибудь знает как его добыть? Как вариант, фильтр может быть сброшен.
Буду благодарен за подсказку.
Шаблон расширяется @extends('main'), внутри которого есть переменные, например {{$title}}
Из документации:
@extends('layouts.app')
@section('title', 'Page Title')а в лейауте эту секцию выводишь через @yield.
В доке не нашел, но будет работать и передача через параметры.
Здесь синтаксис @extends такой же точно также как в @include
@extends('master', ['title' => $title])после чего переменная $title будет определена в master.blade.php
Как мне отойти от стандартов, не отходя от стандартов?
Проверь себя: в шаблоне выведи "сырое" содержимое переменной с ошибками:
@if ($errors->any())
@php(dd($errors))
@endifможет быть всё, что ты хочешь тебе и так доступно, надо только правильно обратиться.
На самом деле надо было не отказываться от посредника CSRF, а добавить в форму поле с токеном, чтобы посредник мог его использовать. Если внезапно и это не поможет, значит проблема в сессии, потому что для проверки токена нужна сессия. Без сессии вам вообще ВСЁ придется поотключать
Короче, старайтесь придерживаться стандартных путей, а не громоздить костыли. Отступать от шаблонов могут только гуру 80-го уровня.
Быстрый вопрос: у вас бюджет или энтузиазм?
Не надо тебе обращаться к другому контроллеру. Всё делается на уровне шаблонов.
То что ты просишь делается через "наследование шаблонов". Не знаю зачем так назвали, на наследование в ООП это не похоже.
В команде @extends указываешь где находятся твои шапка и попка. То, что надо туда передать для вывода обрамляешь в блоки @section или @stack
Чтобы постоянно не передавать одни и те же "глобальные" параметры в каждый вызов, описываешь их один раз во View Composers
Всё нормально описано в офф. доках.
https://laravel.ru/docs/v5/blade
https://laravel.com/docs/5.8/views#view-composers
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)