[LukeTowers]

Replaces #173, continuing the work done by @mjauvin @bennothommo & @wverhoogt

Summary by CodeRabbit

• New Features

  • Added PHP 8.2+ support and modern framework capabilities.
  • Added MariaDB connectivity and improved database support across major platforms.
  • Added configurable authentication password attributes and fluent authentication setup.
  • Added optional pagination totals and improved expression-based searching.
  • Added broader translation path and locale fallback handling.
  • Added customizable application path generation.

• Bug Fixes

  • Improved schema column-change handling across database platforms.
  • Prevented invalid file records from producing malformed results.
  • Improved form value handling and month formatting.

[JonasPardon]

"I don't understand the problem, striping the extra quotes was the whole reason to override getDefaultValue() in the first place."

— @mjauvin on Discord, about item 1 of my notes on wintercms/winter#1366

Agreed, stripping the extra quotes is needed: some databases report a column's default as a quoted SQL literal, so a default copied back from getColumns() would otherwise be quoted twice. My point was only about the old implementation, which removed every ', including apostrophes inside the value. So ->default("O'Brien") on a new column became 'OBrien', and on MySQL, which reports defaults unquoted, ->change() rewrote an existing O'Brien default to OBrien.

Your 0f69f95 fixes both. One case is still left: databases that report the default as an SQL literal also escape the quotes inside it, for example 'O''Brien'. Removing only the outer pair leaves O''Brien, which parent::getDefaultValue() escapes again.

Here's your current override run on Laravel 12.69.3, next to the same override with the inner quotes unescaped as well:

Input to getDefaultValue()	Current (0f69f95)	With str_replace("''", "'", …)
O'Brien (from a migration, or MySQL getColumns())	'O''Brien'	'O''Brien'
'foo' (MariaDB/SQLite getColumns())	'foo'	'foo'
'O''Brien' (MariaDB/SQLite getColumns())	'O''''Brien', so the stored value becomes O''Brien	'O''Brien'
'O'Brian' (your test input)	'O''Brian'	'O''Brian'

Suggested change, which keeps your tests passing:

$value = str_replace("''", "'", substr($value, 1, -1));

and a test case with default("'O''Brian'") next to the existing "'O'Brian'" one.

I checked that SQLite's getColumns() returns 'O''Brien', but I haven't run MariaDB. Its information_schema documents the same escaped format. The SQLite ->change() path already keeps such a default intact, so this mainly matters for MariaDB through MySqlBasedGrammar::compileChange().

🤖 Generated with Claude Code

[mjauvin]

@LukeTowers @JonasPardon I don't think we need to override Mail::fake(), it doesn't differ from the base Laravel version.

Or is there something special about our MailFake maybe that we need ?

We should at least drop the argument, it's not needed and Laravel doesn't have it either.

[JonasPardon]

I don't think we need to override Mail::fake(), it doesn't differ from the base Laravel version.

@mjauvin It does differ, even though the body mirrors Laravel's:

1. Storm's Mail facade extends the base Facade, not Illuminate\Support\Facades\Mail, so without the override there is no fake(): Mail::fake() is forwarded to the mailer and throws Method Illuminate\Mail\Mailer::fake does not exist.
2. Its accessor is mailer, while Laravel's is mail.manager. Laravel's fake() passes the facade root to MailFake, which requires a MailManager, so extending Laravel's facade instead fails with MailFake::__construct(): Argument #1 ($manager) must be of type Illuminate\Mail\MailManager, Illuminate\Mail\Mailer given. The override resolves mail.manager itself.
3. It creates Winter's MailFake, which turns Mail::send('acme.blog::mail.welcome', $data, $callback) into a mailable. Laravel's MailFake ignores anything that isn't a Mailable, so Mail::assertSent() wouldn't see Winter-style sends.

I checked 1 and 2 by removing the override on wip/1.3 and running tests/Support/MailFacadeTest.php.

[mjauvin]

@JonasPardon I agree with your answer above. But I think we can drop the mailmanager argument.