I have some thoughts against that.

Manipulating data in migrations makes sense on production only.

Migrations are "replayable" - they are applied one after another many times during development and testing. You can launch php artisan migrate:fresh hundred times while developing on your local dev machine. If you have data manipulation inside one of your migrations which data is actually manipulated on dev machine? And why? Testing/dev data is seeded many times (and AFTER all migrations, not among them), it doesn't need to "evolve" along with migrations.

To have "data migration" properly tested I have to seed database with various sets of data instead of only latest version. I have to track different data sets to always match with different DB schemas/migrations. I don't think this is worthwhile.

Therefore, I wouldn't place data manipulation inside migration. Instead I would use Artisan command which is launched manually on production only and one time only, after a corresponding migration is applied.

This package offers something similar: https://github.com/TimoKoerber/laravel-one-time-operations

Quote from description:

This package is for you if... ... you often seed or process data in a migration file (which is a big no-no!)

I wouldn't hire you for one very simple reason (and it has nothing to do with your lack of understanding of what you actually need to do to become a developer from the development end of the wedge)... the sole reason is:

You simply don't listen/take on board anything that people that do know, advise you.

How many times across both of your accounts have extremely experienced engineers told you to ignore buzzwords, all these acronyms and everything else that some PoS AI is telling you? How many of those many times, have you once taken on board that invaluable information and put it into practice?

In fact, at this point, I can only assume that both of your accounts have not been set up to glean information from engineers here, but are nothing but pure troll accounts... for which this, you have apparently succeeded.

The only reason I have wasted digital ink in this reply is that I'm waiting for a CI pipeline to complete and I find your posts humorous.

Remember.. it's "in.... out... in.... out"... just in case you were also wanting to know how to breath.. or how it might be more relevant to you.. engage your respiratory system, expand your nasal cavities.. contract your diaphragm to increase space in the chest cavity. Allow the air to travel down your trachea into your lungs.. then begin to exhale and allow the CO2 to leave your body.

With this information.. you should now also be able to become a brain surgeon!

Jesus christ!

If that's your senior engineer writing that code today, they need to be sacked, ASAP!

That's not code written by a senior! They might have been there a long time, but they are not a senior engineer.

I would replace optimised with streamlined maybe.. IMO, leans more on the "convenience" grammar than "technically tweaked" as such.

While I'm in the docker pit for development and wouldn't develop PHP natively in windows (been there, done that 20+ years ago).. I can see the appeal of this kind of setup for people.. let's face it, even with a myriad tools for building your own stacks (of which you can easily "template"), people love herd and valet etc.. so there's a market for it.. especially if it's free and can compete with herd's paid-for features.

Even that aside.. if it's been a technical challenge for you and and offers self-achievement, then I'd say that's a win and a bonus if it becomes more widely adopted 👍🏻

Good luck with the venture! 🙂

They were on some kind of drive to turn Laravel PHP stuff into JS it felt like at one point, especially with Pest and Volt.. both of which, IMO, are a royal PITA and a mess to work with.

Also, I'd highly recommend not using env() in the code, rather Config::get() as the former will cause you issues when you cache the config in production.

I find the One Time Operations a nice package for handling these "one-offs" as they work like migrations, can run them async of synchronously out of the box and means you keep the migrations for what they're designed for, schema definitions.

Sounds like Lary should be renamed 'Clippy' with an opening line like that!

@JeffreyWay I posted a reply in the comments on this video (it was a reply to the reply to my OP). The comments count says 4 but there's only 3 visible.. seems my 2nd post there is hidden somewhere?

@jonmbt It certainly was a test, that's for sure! I know it's not the same now.. but it was also waaay before we had the likes of Carbon for a nicer date API (not that it really mattered.. that would only help so much).

I think it was housed in Typo3 so that CMS features for internationalisation could also be offered, as the same company also had European branches too (though I think the US company seems to have just adopted the first part of the name now). Luckily, the Euro sites were far less dictating in what/how we stored the data. As long as it functioned how it was meant to, and we could generate reports and appointments in human-readable format, the rest was down to us... thankfully!

The scary part was, is that the DB was accessed by humans, as we also had to make a phpMyAdmin instance available for the US too..... yeah... would could possibly go wrong with that.... more than once? (luckily, I didn't have to do too much in the way of sysadmin there).

I like that... "store in the DB as UTC, no exceptions!"

My worst nightmare was developing a booking funnel application for a well-known auto glass replacement company in the US. The development and hosting was in the UK, but the company insisted that the date/time info was stored in the EST timezone due to HQ being in Columbus, Ohio IIRC, and it had to be "humanly readable" in the database too (no unix timestamps etc... why? your guess is as good as mine!).

This was an absolutely massive nightmate having to do conversions between the dates/times with the server set to UTC.... but then of course, there was something like 48 or so States to cover too... a couple of which I found out at the time don't follow summer time changes either. This was back in ~2009.. the application was written using ZendFramework, that was hosted inside of a "page" component in Typo3... I'll leave the rest to your imagination 😃

It seems when comments (largely spam) are removed from a thread, the thread still remains as a recently updated thread, when in reality, it's not if it's had the last record removed.

Would be great to see the date reset to the last comment date so that 2 year old (for example) threads don't appear in the latest updated threads.

This thread for example: https://laracasts.com/discuss/channels/general-discussion/good-video-service-for-an-education-saas

Last post was 2 years ago. A spam post was removed today, but it's listed in the forum index as 'last updated 8h ago'. Yes, it was, if you treat the last updated timestamp as a literal action (removal of the post) but it actually has no correlation with the thread content and shouldn't be listed as a recent thread.

Tailwind 4 moved away from the tailwind.config.js file (don't know if it still gets read, but the auto-updater will remove it). Everything is defined in the CSS file now.

In one of my recent projects, I defined this as:

@import 'tailwindcss';
@import 'typography.css';

@plugin '@tailwindcss/forms';

@source '../../vendor/laravel/framework/src/Illuminate/Pagination/resources/views/*.blade.php';

@theme {
  --font-sans:
    IBMPlexSans,
    Figtree, ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji',
    'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji';

  --font-mono: Lilex;
}

/*
  The default border color has changed to `currentcolor` in Tailwind CSS v4,
  so we've added these compatibility styles to make sure everything still
  looks the same as it did with Tailwind CSS v3.

  If we ever want to remove these styles, we need to add an explicit border
  color utility to any element that depends on these defaults.
*/
@layer base {
  *,
  ::after,
  ::before,
  ::backdrop,
  ::file-selector-button {
    border-color: var(--color-gray-200, currentcolor);
  }
}

typography.css contains:

@font-face {
    font-family: IBMPlexSans;
    font-style: normal;
    font-weight: 100 900;
    font-display: swap;
    src: url("../../public/fonts/IBM-Plex-Sans-Var-Roman.woff2") format("woff2");
}
@font-face {
    font-family: IBMPlexSans;
    font-style: italic;
    font-weight: 100 900;
    font-display: swap;
    src: url("../../public/fonts/IBM-Plex-Sans-Var-Italic.woff2") format("woff2");
}

@font-face {
    font-family: Lilex;
    font-style: normal;
    font-weight: 100 900;
    font-display: swap;
    src: url("../../public/fonts/Lilex[wght].woff2") format("woff2");
}

.font-sans,
input,
select,
option,
button,
textarea {
    /*font-feature-settings: "ss01", "ss02", "ss03", "cv11";*/
    /*font-feature-settings: "cv02", "cv11", "ss01";*/
    font-feature-settings: "calt", "ss01", "ss03", "cv05", "cv06", "cv08", "cv10", "cv11";
    font-variation-settings: "opsz" 32;
}

.font-mono {
    font-feature-settings: "ss01", "ss02", "ss03", "cv11";
    font-variation-settings: "opsz" 12;
}

.fraction {
    font-feature-settings: "frac";
}

It doesn't use external fonts, but maybe the rest of the setup is the same.