PHP Reddit – Telegram
PHP Reddit
34 subscribers
286 photos
36 videos
24.7K links
Channel to sync with /r/PHP /r/Laravel /r/Symfony. Powered by awesome @r_channels and @reddit2telegram
Download Telegram
Static Methods Vs. Lazy Objects | PHP

Why should I use the lazy objects instead of static methods? I don't understand the difference use case of them.

https://redd.it/1oyfzzc
@r_php
Should I opensource my DI container?

I've been using a custom dependency injection container in a couple of my php websites recently it's ~35 lines and still has all the features I need. It's explicit (so no autowiring) and has an emphasis on developer experience despite being so small, it has helper methods for factories, singletons, and lazy singletons. I've found it ideal for no/micro framework projects, cli noscripts, and possibly for use in laravel packages. What do you think? Is this something worth sharing?

https://redd.it/1oyj0u1
@r_php
Weekly /r/Laravel Help Thread

Ask your Laravel help questions here. To improve your chances of getting an answer from the community, here are some tips:

What steps have you taken so far?
What have you tried from the documentation?
Did you provide any error messages you are getting?
Are you able to provide instructions to replicate the issue?
Did you provide a code example?
Please don't post a screenshot of your code. Use the code block in the Reddit text editor and ensure it's formatted correctly.

For more immediate support, you can ask in the official Laravel Discord.

Thanks and welcome to the r/Laravel community!

https://redd.it/1oysfch
@r_php
EHTML — Extended HTML for Real Apps. Sharing it in case it helps someone.

Hi everyone! I’ve been working on a project called EHTML, an HTML-first approach to building dynamic pages using mostly HTML. It lets you handle things like templating, loops, conditions, data loading, reusable components, and nested forms — all without a build step or heavy JavaScript setup.

I originally built it to simplify my own workflow for small apps and prototypes, but I figured others who prefer lightweight or no-build approaches might find it useful too. It runs entirely in the browser using native ES modules and custom elements, so there’s no bundler or complex tooling involved.

If you enjoy working close to the browser or like experimenting with minimalistic web development, you might find it interesting. Just sharing in case it helps someone or sparks ideas. Cheers!


Link: https://e-html.org/

https://redd.it/1oyv9xw
@r_php
Show the progress of your background jobs in your UI and support cancelling running jobs safely
https://redd.it/1oyynco
@r_php
Weekly Ask Anything Thread

Feel free to ask any questions you think may not warrant a post. Asking for help here is also fine.

https://redd.it/1oz6q1c
@r_php
Weekly help thread

Hey there!

This subreddit isn't meant for help threads, though there's one exception to the rule: in this thread you can ask anything you want PHP related, someone will probably be able to help you out!

https://redd.it/1oz9n6n
@r_php
Disappointed in Laracon AU

It's a trend I've noticed over the last few years, but Laracon AU was probably the final straw.

All credit to Michael and the Laracon AU team, I know organising such an event can't be easy, but the lack of technical talks at what is meant to be a technical conference was really disappointing. And I'm not the only one - my entire team was really disappointed.

For context, we're all senior engineers from 7 to 20+ years experience, and Laracon (of which I've been to 7 across the world) used to be very technical in nature. It either had lots of cool Laravel stuff (such as deep dives into the framework), business stories regarding challenges that were solved, or PHP-related stuff, such as design pattern implementation talks or DDD content.

But of all the talks that were there, only 2 were somewhat technical. First there was James' talk on Laravel Forge and some of the decisions and solutions made there (which was my favourite of the two days), or Auth factories by Mary, which was unfortunately hamstrung by her confusing presentation of the use of factories in Laravel (which weren't wrong, but was convoluted by poorly-communicated examples). I could see what she was going for, but after talking with other seniors at the conference, they were also really confused and found it hard to follow.

Lastly, Jason McCreary's talk on Blueprint was interesting, but not really aimed at senior engineers.

In reality, there was literally no content that provided any value to senior engineers, and so the value of the conference to us was zero.

This is not what Laracon used to be. Half our team also went to the last Laracon EU and felt the same way - that the value of the conference for senior has gone down.

It seems to me the conference is now only aimed at beginners, in addition to an underlying thread of political points that have been present since 2016 and is honestly rather trite.

I really hope this changes, as we've discussed internally that'll likely be the last Laracon we attend, and instead look to other conferences - and I think that's really unfortunate. I have such fond memories of the first few laracons in US/EU and always came away inspired and refreshed, so it's disappointing that the last few have left me feeling rather empty.

I know this feeling isn't universal, I spoke to several other people who enjoyed the conference, but for me and my team, it's hard to be excited about future Laracons.

https://redd.it/1ozdebg
@r_php
Web Socket (Soketi)

Has anyone worked with Soketi (https://docs.soketi.app) as a WebSocket server?

I'm trying to integrate Soketi into my application. I already have it working in my local environment, but I'm having trouble getting it to work in production.

The production environment is a bit more complex than local. The Laravel application runs on two different servers behind a load balancer, and I need to host the Soketi server on a third server for scalability purposes. However, I haven't been able to make it work.

Has anyone dealt with a similar setup and could provide some guidance?



PS: The application is multi-tenant.



https://redd.it/1ozffxp
@r_php
You should reinstall Claude Code

I experienced this exact thing over the weekend. Couldn’t figure out why running php artisan test was wiping out the data in my dev db. Hopefully this helps others out as well

https://x.com/matthieunapoli/status/1990092916690501957?s=46&t=5eaP5DWavAxUxYvsVFS-Kw

Claude Code users (especially Laravel/Symfony): you REALLY want to re-install Claude

Latest Claude versions will load your .env (including secrets!) into Claude Code. Claude then runs your tests with local config instead of testing config!

I found this because my Laravel tests in Claude Code failed with CSRF errors (419), but pass in my terminal.

That is caused by @bunjavanoscript (NodeJS alternative).
Claude Code recently moved from "install via NPM and run via Node" to "download a self-contained binary". Except that binary is running Bun under the hood.
And Bun automatically loads .env files (wtf!)

Which means that your Laravel local config (.env) gets loaded, forcing tests to run in local environment instead of testing, with your entire local config (including tokens & such). If your local DB gets wiped because of Claude, you now know why.

You really want to move back to the npm version of Claude Code:

rm ~/.local/bin/claude
npm install -g @anthropic-ai/claude-code

https://redd.it/1p02w90
@r_php
Laravel conventions as a mantra for development, is wrong (maybe)

First let me state upfront that conventions by themselves are not a bad thing. They provide an easy, simple, jumping-off point for new developers, as well as h3lp (*the real word prevents me from posting here - wtf?*) with cross-project onboarding, and familiarity. However, a trend I have been aware of for quite some time is that we should not change these conventions, that we should leave them alone. That is both an ideological and unrealistic viewpoint to hold. As developers, we ***need*** to be more pragmatic than this.

I regularly feel that many in the Laravel community have never worked on large, long-lived, complex projects, including those who speak regularly and are often considered the face (or faces) of Laravel. I am not however, referring to Taylor or any others of the Laravel team.

One of the main reasons I have been using Laravel since version 3, is the fact that the framework gets *out of my way*, when I need it to. Before Laravel, there had not been a single web framework I had used where I was not fighting it to do what I needed, including Ruby on Rails. With Laravel, I've ***almost*** ***never*** had that problem. Laravel establishes sensible conventions, but you can change or ignore these conventions in favour of approaches that better align with your business requirements or technical challenges, as the need arises.

I also want to be clear that when I talk about "Laravel conventions", I am not necessarily talking about the way in which a new Laravel application is created, but also community-led or supported conventions.

So why do I think Laravel conventions are not great for large projects, and why do I think that claiming that you should only stick to conventions, is a fallacy?

# 1. Directory structure by file type

This is (in my humble opinion) the worst laravel convention. However, I acknowledge that it is likely the easiest mental frame for many to adopt, as it requires little to no context of the application you're working on. Need a controller? No problem, head to the Controllers directory. Looking for models? You know where to find them. However, in a large application, this very quickly falls apart, as you can easily end up with 100s of controllers, models, form requests, anything - and this makes the provided structure difficult to work with, as it implies that all these things are related. They're not. The only thing have in common, is the type of PHP file that they are.

Secondly, this results in related code being split across the application, rather than living next to one another. For example, were I to look at a single request lifecycle, I'd likely need to go to FormRequest directory, a Controllers or Actions directory, the Models directory, perhaps some another Services directory.etc.etc.

It is my opinion that folder structures should be as flat and simple as possible, until such time as it actually makes sense to start categorising your project's files in some other way. This also forces you to be more careful with the naming of those files, classes.etc.

Let's start with a made-up set of features around Users. Perhaps we support registration and profile management, a routes.php file for all user endpoints, a User model, a bunch of form requests.etc. An initial starting point, might look like the following:

* User.php
* RegistrationController.php
* ProfileController.php
* RegistersUser.php <- FormRequest
* SendEmails.php <- listener for sending notifications/emails
* UserRepository.php
* Users.php <- Collection
* UsersServiceProvider
* routes.php

Now whether you like or dislike this approach, is irrelevant for the moment. The fact is that everything related to user registration, profile management, persistence, notifications and validation are all here. I can see it all in app/Domains/Users (as an example). I even have a routes file that registers only the routes specific to those requirements. In short, I can see a complete, vertical slice of this particular domain/subdomain at a glance.

Now I know what