These functions allow encoding and decoding base64 data in SQL queries,
matching the behavior of their MySQL counterparts. They are registered
as SQLite user-defined functions backed by PHP's base64_encode() and
base64_decode(), so both the legacy and AST-based drivers can use them.

FROM_BASE64() returns NULL for NULL or invalid base64 input.
TO_BASE64() returns NULL for NULL input.

## Summary

This adds support for MySQL's `FROM_BASE64()` and `TO_BASE64()`
functions, allowing SQL queries to encode and decode base64 data.

Both functions are implemented as SQLite user-defined functions backed
by PHP's `base64_encode()` and `base64_decode()`. Because they're
registered through
`WP_SQLite_PDO_User_Defined_Functions::register_for()`, they work with
both the legacy and AST-based drivers automatically.

`FROM_BASE64()` returns `NULL` for `NULL` or invalid base64 input.
`TO_BASE64()` returns `NULL` for `NULL` input.

## Test plan

- Run `composer run test -- --filter 'testFromBase64|testToBase64'`
- Verify basic encoding/decoding, NULL handling, empty string handling,
and round-trip correctness

…ws (#325)

### Summary

Fixes #322 

WP_SQLite_Driver::query() returned null instead of 0 for statements
affecting zero rows (e.g., DELETE FROM x WHERE id = 1 when no matching
row exists). This caused wpdb::query() to also return null, breaking its
documented contract of returning int|bool.

### Problem

In WP_SQLite_Driver::query(), the return logic for non-SELECT queries
was:

1. rowCount() > 0 - return row count
2. Otherwise - return null

This meant any DELETE, UPDATE, INSERT statement with 0 affected rows
returned null instead of 0.

### Fix

Simplified the logic to always return rowCount() for non-SELECT
statements.

DELETE / UPDATE / INSERT will now correctly returns 0 instead of null
when no rows affected.
CREATE / ALTER / DROP / TRUNCATE now returns 0 instead of null, but
wp-includes/sqlite/class-wp-sqlite-db.php never reads this value for
these queries (it returns true unconditionally at line 448-449)

### Testing

- Added testDeleteReturnsZeroAffectedRowsWhenNoMatchingRows - verifies
DELETE returns 0 when no rows match.
- Added testUpdateReturnsZeroAffectedRowsWhenNoMatchingRows - verifies
UPDATE returns 0 when no rows match.
- Updated existing test assertions from assertNull to assertSame( 0, ...
) to reflect the corrected behaviour
- Full test suite passes (777 tests)

… off

MySQL's behavior around zero dates ('0000-00-00') and dates with zero
parts ('2020-00-15') depends on two SQL modes: NO_ZERO_DATE and
NO_ZERO_IN_DATE. Both are enabled by default in MySQL 8.0, but
applications can disable them.

Previously, the SQLite driver always rejected zero dates through
SQLite's DATE()/DATETIME() functions, which return NULL for such
values. This caused incorrect errors when strict mode was on but
the zero-date modes were off.

Now the CASE expression in cast_value_for_saving() checks the active
SQL modes and inserts additional WHEN clauses to accept zero dates
when appropriate. The translate_datetime_literal() method also
preserves dates with zero month/day parts when NO_ZERO_IN_DATE is off,
instead of truncating them via strtotime().

Instead of conditionally building $zero_date_whens in PHP, the WHEN
clauses are always present in the CASE statement with the SQL mode
check embedded as a literal boolean (AND NOT 0/1). This keeps the
generated SQL structure consistent regardless of active modes.

One argument per line in the sprintf call, align equals signs,
and use single quotes for CREATE TABLE string in tests.

Replace sprintf with strtr so each substituted value appears once in the
argument list and the template reads like annotated SQL.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…, not the raw value

The strtr refactor accidentally changed `WHEN $function_call > '0'`
to `WHEN {value} > '0'`, comparing the wrong operand and breaking
date validation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Verify that UPDATE statements produce errors for zero dates and
zero-in-dates when strict mode is combined with NO_ZERO_DATE or
NO_ZERO_IN_DATE, matching the existing INSERT rejection tests.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add tests verifying that stored zero dates and zero-in-dates can be
selected, compared, ordered, and filtered – matching MySQL behavior.

Fix YEAR(), MONTH(), and DAY() functions to return 0 for zero date
parts. Previously, strtotime() couldn't parse dates like '0000-00-00'
or '2020-00-15', producing wrong results. Now the date parts are
extracted directly from the string when possible.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The PHP manual references for format specifiers used by gmdate()
were accidentally removed when adding zero-date handling. These
comments document why specific format characters (n, Y, j) are
used in the fallback path and should be preserved.

Add ^ anchors to the YEAR/MONTH/DAY regex patterns so they only
match date strings starting at the beginning of the input, not
arbitrary substrings.

## Summary

MySQL controls zero-date acceptance through two SQL modes:
`NO_ZERO_DATE` and `NO_ZERO_IN_DATE`. Both are on by default, but
applications can turn them off to allow values like `'0000-00-00
00:00:00'` or `'2020-00-15'`. The SQLite driver wasn't honoring these
modes – SQLite's `DATE()`/`DATETIME()` functions return NULL for zero
dates, so they always fell through to the strict-mode error, even when
the zero-date modes were disabled.

This PR adds zero-date acceptance checks to `cast_value_for_saving()`
that inspect the active SQL modes before rejecting a date. When
`NO_ZERO_DATE` is off (or on without strict mode), all-zero dates pass
through. When `NO_ZERO_IN_DATE` is off, dates with zero month/day parts
like `'2020-00-15'` are accepted too. The `translate_datetime_literal()`
method is also updated to preserve zero-part dates instead of truncating
them via `strtotime()`.

The behavior matrix now matches MySQL's documentation:

| Mode combination | `'0000-00-00'` | `'2020-00-15'` |
|---|---|---|
| Both modes off | Accepted | Accepted |
| Mode on, non-strict | Accepted (warning in MySQL) | Stored as
`'0000-00-00'` |
| Mode on + strict | Error | Error |

## Test plan

- [x] 12 new PHPUnit tests covering all combinations of NO_ZERO_DATE ×
NO_ZERO_IN_DATE × strict mode
- [x] Full test suite passes (772 tests, 0 failures)
- [ ] Review that WordPress core's `test_insert_empty_post_date` still
works with default modes

…329)

This PR adds the `3948349` integer as the [SQLite Application
ID](https://sqlite.org/fileformat.html#application_id) that is standard
procedure to take when a SQLite database is used as an application file
format[^1]. A new consistent file extension has been chosen.

1. `PRAGMA application_id = SQLITE_DB_APPLICATION_ID` is set for new and
old databases
2. New databases are created with the new file extension
3. Legacy files are renamed for backward compatibility

[^1]: https://sqlite.org/appfileformat.html