"Blueprint" generates code for your #Laravel app. Create draft.yaml, define what to generate, package handles the boilerplate stuff for you. This example generates a controller, factory, migration, model and test. Very neat to begin a project with.
Currently updating one of our biggest sites from #Statamic v3 to v5. 1000+ entries and multisite. At first I thought it would be a pain but seeing how everything looks "new" now and feels lighter is absolutely worth the effort
#Laravel ships with a collection helper 'chunkWhile' that lets you chunk a collection while a given condition is met. Once the condition is no longer met, a new chunk is started and so on. Example: Grouping dates by day.
I think in English when you write formal text you spell the numbers until 10. From there on you just write the number. #Laravel can help with that using the 'Number::spell' helper.
TIL that #Statamic ships with the 'isCpRoute()' function, which allowed me to make my code a little more compact. The function will check if the current route is a control panel route or not. Here's the old and new code. Feels refreshing 😁
The last few days I've shown some examples of how I use macros in #Laravel for certain classes in my daily work. In case you enjoy using macros as much as I do, here's a list of some popular and frequently used classes that implement the Macroable trait that you might not yet have on your radar.
Just published a new release of one of my #Statamic addons. But first I rewrote the whole thing, then updated the README, noticed that half of my code is not necessary, rewrote the whole thing, then updated the README again. That's how I work.
I've running into an issue and couldn't figure out what's going wrong. I'm trying to load some traits in my Laravel 10-factories, but every time I receive a message the trait is already declared and in use. Is anyone familiar with this issue and could help me to solve it? #Laravel
Any #laravel devs in DE looking for a job or freelance gig at the moment?
Must be fluent-ish in German and able to work in a codebase that heavily relies on Vue (though if you have experience with Svelte, react, or another modern reactive JS framework other than Vue that would be fine).
I have just learned that "#Java Bean" has two completely different and incompatible definitions.
One is a dumb, badly designed data object with getters and setters.
The other is... a service object managed by the Spring framework IoC container.
Holy hell. This is 10x worse than #Laravel "facades."
Am I wrong here? This is what I'm finding from online tutorials. Is there more nuance that is not coming through, because for now I just hate #Spring even more.
Macros are one thing I enjoy using the most in #Laravel. It's a way to extend the functionality of many built-in #Facades by providing custom callbacks for a specific key.
One production example I use macros for fairly often is what I call the "admin alert". Especially in smaller applications I want to get notified whenever an error or an event occurs the admin (mostly that's me) should know about.