Laravel по-русски

Я сомневаюсь, что много кто болезненно реагирует на изменение числа своих папугаев. Это ж не Хабр.

Такое бывает.

Ограничения не нужны, если кто-то мусорит - я эти посты удаляю, они долго не держатся. А плюсики это так, баловство. Если и делать какую-то играизацию (gamification), то надо менять движок форума на Discourse или подобный (что повлечет за собой потерю всех постов).

Учатся не задавая вопросы на каждый чих, а пытаясь разобраться самому, а затем, если не помогло, формулируя вопрос и излагая варианты решения или идеи, которые пробовали. При таком подходе большая часть вопросов или отсекается ("что такое массив $fillable"), или оказывается лишенной смысла ("как написать Интернет-магазин"). А вы засоряете форум и заставляете многих людей делать за вас эту работу.

Вот хорошие примеры вопросов: тыц, тыц, тыц. Учитесь на здоровье.

Это универсальный фреймворк и для таких вещей он вполне подходит.

Command 'сhown' not found, did you mean:

  command 'chown' from deb coreutils

Try: sudo apt install <deb name>

Вот же тебе пишут: "команда не найдена, может ты хотел такую-то из такого-то пакета? если да, то выполни то-то".

sudo apt install coreutils

Далее:

sudo chown -R www-data: /var/www

P.S: artoodetoo - после : не обязательно писать группу, если она совпадает с группой пользователя, что в 90% именно так.

Слишком широкий вопрос. Начни со списка OWASP-10 и вообще почитай про этот проект хотя бы на Википедии.

Я как-то написал статью про такую "дыру" в одном существующем движке.

Отключение внешних ключей - плохая идея с точки зрения целостности базы.

Тут однозначного ответа/совета быть не может - у каждого свое понимание ООП (а кто-то вообще против него, хоть таких в PHP не много). Так что ниже сугубо мое личное мнение.

Ты столкнулся с ситуацией, когда излишняя иерархия вредит. Есть две иерархии: плоская (по сути, отстутствие иерархии) или полная (предельная группировка по пространствам имен, как в твоем желаемом примере с App\TelegramBot\Actions\Keyboards\Xyz...).

Когда-то, в PHP до версии 5.3 пространств имен (namespaces) не было. Во многих ЯП их нет до сих пор (Си, JavaScript, Lua и пр.). В этом случае проблема коллизий (совпадений имен, когда у тебя есть класс Foo и у библиотеки тоже есть класс Foo) решалась путем префиксов и суффиксов. Например:

MyTelegramBotKeyboardAction

Когда появились NS и народ кинулся в другую крайность, получилось так:

My\Telegram\Bot\Action\Keyboard

Интересно заметить, что первый вариант гораздо ближе к естественному написанию, чем второй ("my telegram bot's keyboard action" <=> "my telegram bot, (its) action (of/for) keyboard").

А еще интереснее, что многие вообще начинают совмещать оба подхода, и вот это мне совсем не понятно:

My\Telegram\Bot\Action\KeyboardAction

Ясно, что так проще (короче) писать use, но это уже совсем масло-масляное ("ActionKeyboardAction") - может тогда это промежуточное пространство имен вообще не нужно?

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

MyTelegramBot\KeyboardAction

То есть одно большое NS, где внутри все остальное, без под-NS. Такая структура позволяет избежать use практически целиком. Например, если у тебя есть класс App\TelegramBot\Commands\SomeCommand и ему надо вызвать метод у Core, то ты будешь писать так:

class SomeCommand {
  function foo() {
    \App\TelegramBot\Core::bar();

Или так:

use App\TelegramBot\Core;

class SomeCommand {
  function foo() {
    Core::bar();

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

А вот если у тебя и Command, и Core в одном NS - то никаких проблем:

class SomeCommand {
  function foo() {
    Core::bar();

Получаешь лучшее из двух миров - use не надо (ибо классы в одном NS), в то же время ссылаешься на класс, как будто бы use был.

Таким образом, use или пути остаются только для зависимостей (библиотек), но это неизбежное зло и обычно к классам из библиотек обращений на порядок меньше, чем к собственным, так что озвученная проблема особо не стоит.

Я думаю, тебе стоит почитать про ООП в PHP подробнее, потому что у тебя путаница: use не вызывает автозагрузчик и вообще никак не относится к нему. Автозагрузчик сам по себе. Когда ты пишешь use, ты просто создаешь псевдоним для отдельно взятого класса в рамках этого файла: вместо \Some\Class::foo ты можешь написать один раз use Some\Class и далее везде просто Class::foo.

В доке по PHP все очень хорошо расписано:

• Автоматическая загрузка классов

• Использование пространств имен: импорт/создание псевдонима имени

Не обязательно. Любой проект можно разбить на части. Если над проектом планируется, что будет работать один человек - берешь двух, одному фронтенд, второму бекенд. Кто-то из них свалит, останется второй, который доделает эту часть и переключится на вторую. Или обоим бекенд, но разные части (например, админка и клиентский, или каталог/корзина и тикеты).

Все это от характера конкретного проекта зависит, и от изобретательности заказчика тоже, конечно.

Например, учитывая, что народ по большей части разбегается в течении первых пары недель, можно поручать экспериментальные задачи - набросать интерактивный прототип дизайна, или какой-нибудь импортер из Excel'я (если это интернет-магазин). Таких мелких задач всегда можно набрать с десяток, а давать их уже проверенному человеку обычно как раз не хочется из-за того, что часть пойдет на выброс. В то же время именно эти задачи достаточно конфликтны и это хорошая проверка для людей (кто-то просто на дух не выносит кнопочки по экрану двигать, так что готов заказчику дать в физиономию, и лучше это выяснить сразу).

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

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

Я не говорил, что надо оценивать по скорости работы. Человек может работать медленно, но регулярно держать связь. Если используется таск-менеджер - там видно обновления, если GitHub или другой подобный сервис - там коммиты, если их нет, но он "вникает" - значит, на почту приходят вопросы, отчеты раз в день/неделю/месяц, никаких тебе "завтраков" и так далее. Даже когда "дольше пишешь" - у тебя хоть десяток строчек в день есть. Не должно быть такого, что человек на неделю куда-то пропал. Да даже на два дня не должно быть. Не появился на горизонте, когда обещал - жди день и все, считай что исчез (ибо дальше с ним будет почти наверняка хуже). Конечно, есть исключения, но когда человек тебе совсем не знаком - лучше "перебздеть", шанс попасть в такое исключение весьма мал.

з.ы: Boris2020, если вам надоели наши разговоры - отпишитесь, я заблокирую тему.

Я поэтому про allow_request и написал. auth.php может проверять файл на наличие, какую-то строку в БД и пр.

Позволять выполнять shell-команды из PHP - плохая идея с точки зрения безопасности.

Вообще, желательно, чтобы веб-сервер выдавал плашку "обслуживание", а не само приложение. С сервером нет шансов, что какие-то запросы "протекут" (потому что для них middleware не работает или еще что-нибудь подобное). В случае с nginx это делается добавлением набора allow/deny в блок server или location:

allow 1.2.3.4;
allow 5.6.7.8;
deny all;

Но есть и более интересный способ, про который мало знают. В nginx есть опция auth_request - с ней вопрос об аутентификации можно решать в контексте приложения! Когда приходит внешний запрос, nginx опрашивает этот URL и если в ответе код 401 или 403 - пользователю дается "отлуп" (который можно показать в виде красивой кастомной страницы об ошибке путем error_page). В отличии от ручного прописывания allow/deny, здесь не нужно править конфиг сервера, перезапускать его, вообще лезть в консоль, да и гибкость куда большая.

Выглядит это примерно так (подробности в документации):

server {
  ...

  error_page 403 /403.html;

  location / {
    auth_request /auth.php;
    include fastcgi.conf;
  }

  location = /auth.php {
    include fastcgi.conf;
  }
}

Это стандартное поведение, наверное, всех веб-серверов. Если по адресу есть директория, а URL не оканчивается на слэш - до PHP/Laravel такой запрос даже не доходит - редирект возвращает сам веб-сервер. А в чем проблема? Ты хочешь, чтобы по адресу .../blog отдавалась одна страница, а по адресу .../blob/ - другая?

Это плохая идея, будет путаница и, вероятно, с SEO тоже вызовет проблемы. Решение, если и есть, зависит от конкретного используемого веб-сервера (что еще одна причина не ломать стандартное поведение - сложно будет поддерживать).

Потому что народ этим злоупотребляет. Решил проблему - напиши, как, а не удаляй вопрос.

Если запостил что-то личное - нажми "Пожаловаться", я удалю.