The 200-byte trap: why WordPress core updates break Arabic URLs

You update WordPress on a quiet afternoon — a routine release, the kind you've
installed a hundred times. The dashboard says everything went fine. Then the
404s start: not a handful, but every long-headlined article in your archive, all
at once, all in Arabic.

Nothing in the update log mentions it. No plugin changed. And the cruel part:
the data that made those URLs work is already gone — shaved off inside a
database-upgrade routine that ran for a few milliseconds and reported success.
This isn't a freak accident or a broken plugin. It's three separate assumptions
baked into WordPress core, each hard-coding the same number — 200 — and
Arabic sites are almost uniquely exposed to all three. We hit this running
WordPress for Arabic newsrooms, the same high-traffic publishing we've written
about surviving breaking-news spikes.
We traced it to the exact lines in core and built a fix that survives every
future update. Here's the whole story.

Why Arabic URLs hit a wall English never does

WordPress stores a post's slug in the post_name column of wp_posts, and a
category or tag slug in the slug column of wp_terms. Both are VARCHAR(200)
by default — room for 200 characters, which for an English headline is generous.
"Everything you need to know about our new pricing" is barely fifty. You'd have
to write a paragraph to run out.

Arabic is a different arithmetic, because of what WordPress actually stores in
that column. It doesn't keep the raw Arabic text — it stores the
percent-encoded form, the same %XX sequence that travels in the URL. Take a
single word:

الذكاء  →  %d8%a7%d9%84%d8%b0%d9%83%d8%a7%d8%a1

Every Arabic letter is two bytes in UTF-8, and every byte becomes a
three-character %XX token. So one Arabic character costs about six characters
of column space. Do the division: VARCHAR(200) holds roughly 33 Arabic
characters. A normal news headline — "القبض على المتهمين في قضية الاحتيال
الإلكتروني" — blows past that before it's halfway done.

So Arabic publishers learn early to widen the columns:

ALTER TABLE wp_posts MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT '';
ALTER TABLE wp_terms MODIFY slug      VARCHAR(1024) NOT NULL DEFAULT '';

VARCHAR(1024) holds about 170 Arabic characters — comfortable. Permalinks
resolve, the newsroom publishes, and the problem looks solved.

It isn't. It's about one-third solved — and the other two-thirds are waiting
for the next core update. (This isn't only an Arabic problem, either: any
non-Latin script that percent-encodes — Persian, Urdu, Hebrew, Greek — hits the
same wall. Arabic publishers just hit it first and hardest.)

The number 200 lives in three places, not one

Here's the insight that turns this from a recurring mystery into something you
can actually close out. WordPress hard-codes "200" in three independent
places, and widening the column only touches the first:

Your ALTER fixes Layer 1's storage. But Layer 2 means that even with a
1024-wide column, every new slug is still cut to 200 bytes before it's ever
saved — unless something on your site already overrode it. (If long Arabic
slugs save correctly for you today, a plugin, your theme, or a past developer
already patched Layer 2 — which means you have an undocumented dependency you
didn't know you were relying on.) And Layer 1, the storage you so carefully
widened, is exactly the one a core update quietly reverts. Let's take each in
turn.

Layer 1 — how a core update erases your column width

WordPress keeps a canonical description of its own database schema, and on every
major update it reconciles the live database against that description. The chain
is short and deterministic:

1. A new release bumps $wp_db_version in version.php.
2. On the next admin request, wp_upgrade() notices the bump and runs the database upgrade.
3. That calls make_db_current_silent(), which calls dbDelta( wp_get_db_schema() ).
4. wp_get_db_schema() is the canonical schema — and it says, verbatim:

post_name varchar(200) NOT NULL default '',
...
slug varchar(200) NOT NULL default '',

dbDelta() then runs a DESCRIBE on every live table, compares each column to
the canonical definition, and for any mismatch emits an ALTER TABLE … CHANGE
COLUMN to "correct" it. Your post_name is VARCHAR(1024); the canonical says
VARCHAR(200); they don't match — so dbDelta dutifully issues a CHANGE COLUMN
back to 200, MySQL rebuilds the table, and every byte past the 200th is
discarded.

Here's the detail that makes it unrecoverable. Years ago, core added downsize
protection to dbDelta — but only for TEXT and BLOB columns (it was
Trac #36748, born from exactly
this kind of data loss). VARCHAR got no such guard. So a TEXT column is safe
from accidental shrinking; your VARCHAR(1024) slug column is not. dbDelta
shrinks it without hesitation, and restoring the column to 1024 afterwards brings
back the width but not the data — those bytes were handed to MySQL and
dropped.

That's why your fix keeps coming undone: always right after an update, always
silently. It isn't a bug aimed at you — it's core doing exactly what it was
designed to do, to a column you were never expected to change.

For accuracy: a separate routine, pre_schema_upgrade(), also runs hand-written
ALTERs, but those are version-gated to historic migrations and won't touch a
modern site's post_name. The reversion you're seeing is dbDelta.

The fix — don't repair the damage, prevent the shrink

The instinct is to write something that detects the reverted column and
re-widens it after each update. Resist it. By the time you can detect the shrink,
the data is already gone — you'd just be putting an empty wider column back over
truncated slugs. The only fix that actually saves the data is one that stops
the shrink from ever happening.

And core hands you the seam to do it. dbDelta exposes a filter,
dbdelta_create_queries, that receives the canonical CREATE TABLE statements
before they're compared to the live database. Rewrite the canonical
post_name varchar(200) to varchar(1024) in that filter, and dbDelta's idea of
"correct" now matches what's actually on disk. It sees no mismatch. It emits no
CHANGE COLUMN. There is nothing to truncate.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, so long Arabic slugs are never truncated.
 *              Prevention-first: dbDelta never even tries to shrink them.
 */
defined( 'ABSPATH' ) || exit;

const SLUG_COLUMN_LEN = 1024;

// Rewrite the canonical schema dbDelta diffs against, so "desired" already
// equals the live 1024-wide column — no CHANGE COLUMN is ever emitted.
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;

    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . SLUG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

That single filter is the whole prevention story for Layer 1, and it's robust in
a way an after-the-fact repair can never be: it runs inside dbDelta, so it
covers every path that triggers a schema reconcile — the admin "database
update required" screen, background auto-updates, and wp core update-db on the
CLI alike.

Where this code lives matters as much as what it does. Put it in a must-use
plugin — a single .php file in wp-content/mu-plugins/ — not a regular
plugin. MU-plugins always load, can't be deactivated from the dashboard, and load
before the upgrade routine runs. And because a core update only ever replaces
wp-admin, wp-includes and the root PHP files — it never touches wp-content —
your guard is guaranteed to still be in place at the exact moment the upgrade
fires. A regular plugin could be deactivated the one time it mattered; don't bet
your archive on a toggle.

Layer 2 — stop new slugs truncating at birth

Prevention on the column keeps your existing slugs safe. But Layer 2 is still
cutting every new slug to 200 bytes at the moment of creation, inside
sanitize_title_with_dashes(). The relevant line, unchanged in current core, is:

$title = utf8_uri_encode( $title, 200 );

That function is attached to the sanitize_title filter, so you can cleanly swap
it for an identical copy that uses a larger byte budget:

// Layer 2: replace core's slug generator with a byte-for-byte copy whose only
// change is the encoding cap. The copy self-tests against core (see below), so a
// future core rewrite of this function is caught instead of drifting silently.
remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    // … the body is line-for-line core, with one change:
    //     utf8_uri_encode( $title, 200 )  →  utf8_uri_encode( $title, 1000 )
    // 1000 leaves headroom under the 1024 column for a "-2" collision suffix.
}

Pick a sane budget — around 1000 bytes (≈ 160 Arabic characters) leaves room
under the column for the numeric suffix WordPress adds to resolve duplicates. You
don't want unlimited slugs; you want enough.

Layer 3 — _truncate_post_slug() — caps at 200 too, but it only runs when a slug
collides and needs a -2 suffix. For unique news headlines that almost never
fires, and it isn't filterable, so most sites can leave it alone. If you
genuinely need more than 200 bytes even on collisions, you take over uniqueness
through the pre_wp_unique_post_slug filter — an advanced case worth a footnote,
not a paragraph.

Keeping the fork honest

Copying a core function buys a maintenance debt: the day WordPress rewrites
sanitize_title_with_dashes(), your copy diverges — silently, which is the exact
failure mode we're trying to kill. Pinning the copy to a core version and re-diffing
by hand works right up until the release someone forgets to check, which on a
long-lived site is when, not if. So don't rely on remembering. Make the plugin
re-diff itself.

The lever: remove_filter() only unhooks the function — sanitize_title_with_dashes()
stays callable. So you can use core's own current code as a live oracle and assert
your fork still agrees with it on short inputs, where neither byte cap fires and
the only thing left that could differ is the cleanup logic:

// Run once per core version. Short fixtures => neither length cap engages,
// so any difference is pure logic drift, not the byte budget.
foreach ( array( 'الذكاء الاصطناعي', 'عاجل: «مهم» اليوم', 'foo/bar — baz' ) as $f ) {
    if ( sanitize_title_with_dashes( $f, $f, 'save' )
         !== asg_sanitize_title_with_dashes( $f, $f, 'save' ) ) {
        // core changed the cleanup logic — log + email ops, and (optionally) fall
        // back to core's generator so slugs cap at 200 again: degraded, but safe
        // and known, never a malformed slug from a stale copy.
    }
}

This beats a source-hash check on two counts. It's semantic, not textual — it
stays quiet when core only touches the length handling (which you override anyway)
and fires only when a change actually breaks your output, so the alerts that do
fire get acted on. And it degrades safely: on drift you fall back to core's exact
behaviour — worst case, new slugs cap at 200 until you re-sync, never a half-encoded
slug from a stale copy. Loud-and-safe beats silent-and-wrong. The full guard (with
the per-core-version cache and the optional fail-safe switch) is in the complete
plugin below.

A tripwire, because silent failure is the real enemy

The filter prevents the known incident. But the failure mode that actually hurt
you was that it happened silently — so the last piece is making sure you'd
never again learn about it from a drop in search traffic. The same MU-plugin can
verify the column widths after every update and shout if anything is wrong:

• Hook upgrader_process_complete to flag that a core update just ran.
• On the next admin request, check the real column widths in information_schema and, if either has shrunk, write to the error log and email ops.
• Expose a WP-CLI command for cron-based monitoring:

# Nightly: verify the slug columns, email ops if either has reverted.
0 3 * * *  cd /var/www/site && wp asg verify | grep -q REVERTED \
           && wp asg verify | mail -s "WP slug schema reverted on $(hostname)" ops@example.com

One discipline to internalise: this tripwire restores confidence, not data.
If it ever reports a reverted column, treat it as an incident, not a self-healing
event — the slugs longer than the new width are already gone and must come back
from a backup. Prevention (the filter) and backups are your safety net; the
tripwire just tells you when to reach for them.

"Isn't VARCHAR(1024) dangerous?" — no, and the reason is reassuring

Widening these columns sounds risky — indexes, utf8mb4, InnoDB limits — and
it's the part people most often get scared off by. It's almost entirely a
non-issue, and one fact explains why:

The index on these columns is a fixed 191-character prefix, independent of
the column's declared length. Core defines KEY post_name (post_name(191)) — it
indexes the first 191 characters whether the column is 200 wide or 1024. Widening
the column doesn't enlarge the index by a single byte.

That dissolves the usual worries:

• Index / InnoDB prefix limits. The old InnoDB prefix ceiling is 767 bytes; WordPress chose 191 because 191 × 4 (utf8mb4's worst case) = 764, just under it. Because the prefix stays at 191 no matter how wide the column grows, you never move towards that limit. (A quiet irony: slugs are stored as percent-encoded ASCII, so they were never going to hit four bytes per character anyway.)
• Row size. VARCHAR stores the actual length of each value, not its declared maximum — a 30-character slug takes ~30 bytes in a VARCHAR(1024) exactly as it would in a VARCHAR(200). Rows don't get bigger because the ceiling moved up.
• Query plans. Lookups use the same 191-prefix index to narrow, then verify the full value. Identical behaviour at 200 or 1024.
• Plugins. SEO plugins, caches and CDNs read post_name and emit longer URLs without complaint.

The genuine risks aren't in steady state — they're tools that recreate the
schema from an old definition: a migration plugin that runs its own
CREATE TABLE, or, most commonly, restoring a SQL dump taken before you widened
the columns. A dump of the current database preserves VARCHAR(1024)
correctly; importing an old structure silently puts you back at 200. Write that
one down in your runbook.

Doing it safely on a site with millions of posts

There's one operational gotcha, and it's about the migration itself, not the
result. Going from VARCHAR(200) to VARCHAR(1024) cannot be an instant,
in-place change. InnoDB only keeps a VARCHAR length change "in place" while both
lengths stay in the same size class — values under 256 use one length byte,
values 256 and over use two. Crossing 255 forces ALGORITHM=COPY: a full table
rebuild. On a wp_posts with millions of rows, a raw ALTER means a long
operation and a problematic lock.

So on a large live site, do the initial widening with an online schema-change
tool, not a bare ALTER:

pt-online-schema-change \
  --alter "MODIFY post_name VARCHAR(1024) NOT NULL DEFAULT ''" \
  --chunk-time=0.5 --max-load Threads_running=50 \
  --execute D=wordpress,t=wp_posts

(gh-ost is an equally good triggerless alternative.) wp_terms is tiny and
takes a plain ALTER without ceremony; wp_posts is the one that needs the
online tool. The rollout that's bitten no one:

1. Back up, and confirm the dump shows VARCHAR(1024) afterwards.
2. Clone to staging, deploy the MU-plugin, and run a real major core update there. Confirm no CHANGE COLUMN appears and the verify command reports OK.
3. Deploy the MU-plugin to production before the next core update — prevention has to be in place ahead of the event it prevents.
4. Widen the production columns off-peak with pt-osc / gh-ost.
5. Add a nightly verify cron and a 404 monitor, so anything unexpected surfaces in hours, not in a month of lost rankings.
6. Keep the MU-plugin in version control, and never import a pre-widening structure dump.

The deeper fix — stop betting your URLs on a column width

Everything above makes Arabic slugs safe. But there's a more permanent way to
think about it, and for a large news archive it's worth the shift: don't let
the URL depend on the slug surviving at all.

Anchor your permalinks on the numeric post ID, and keep the Arabic slug as a
descriptive — but cosmetic — suffix:

https://example.com/123456/الذكاء-الاصطناعي

Resolve the post by its ID, and the slug becomes decoration. If it's ever
truncated, malformed, or edited, the URL still resolves to the right article
instead of 404-ing — and WordPress can 301 to the canonical form. You keep the
Arabic keywords in the URL for search relevance and you become structurally
immune to the entire class of problem. (If you want to stop touching core tables
altogether, you can go one step further and store the long slug in your own
indexed routing table, which dbDelta has no opinion about — but for most teams,
ID-anchored permalinks are the sweet spot.)

That's the difference between patching a bug and designing it out.

The complete plugin

Everything above, assembled into one must-use plugin. Drop it in
wp-content/mu-plugins/arabic-slug-schema-guard.php, widen the columns once with
an online schema-change tool, and all three layers — plus the tripwire — are
handled in a single place. The slug generator is a copy of core's
sanitize_title_with_dashes(); only the byte cap differs.

📦 Prefer it ready-made? The plugin is open-source on GitHub as mantekio/arabic-slug-schema-guard — or composer require mantekio/arabic-slug-schema-guard. Star it, file an issue, or lift it whole.

<?php
/**
 * Plugin Name: Arabic Slug Schema Guard (must-use)
 * Description: Keeps wp_posts.post_name and wp_terms.slug at VARCHAR(1024) across
 *              core DB upgrades, lets core generate long URL-encoded Arabic slugs,
 *              and verifies + alerts after every update. Prevention-first:
 *              dbDelta never truncates, because the canonical schema it diffs
 *              against already says 1024. The slug fork self-tests against core
 *              on each update and can fail safe.
 */
defined( 'ABSPATH' ) || exit;

const ASG_COLUMN_LEN = 1024;  // physical column width (bytes)
const ASG_SLUG_BYTES = 1000;  // max generated slug length, under the column width
const ASG_SCHEMA_SIG = 'post_name:1024;slug:1024';
// define( 'ASG_ALERT_EMAIL', 'ops@example.com' );  // optional, set in wp-config.php
// define( 'ASG_L2_FAILSAFE', true );               // optional: on Layer-2 drift, fall back to core (slugs cap at 200) until you re-sync

/* LAYER 1 — PREVENTION
 * Rewrite the canonical CREATE TABLE dbDelta diffs against, so "desired" already
 * equals the live 1024-wide column and no destructive CHANGE COLUMN is emitted. */
add_filter( 'dbdelta_create_queries', function ( $queries ) {
    global $wpdb;
    foreach ( array( $wpdb->posts => 'post_name', $wpdb->terms => 'slug' ) as $table => $column ) {
        if ( isset( $queries[ $table ] ) ) {
            $queries[ $table ] = preg_replace(
                '/(\b' . $column . '\s+varchar\()\s*200\s*(\))/i',
                '${1}' . ASG_COLUMN_LEN . '${2}',
                $queries[ $table ]
            );
        }
    }
    return $queries;
} );

/* LAYER 2 — GENERATION
 * Core caps new slugs at 200 bytes via utf8_uri_encode($title, 200). Swap in a
 * copy of sanitize_title_with_dashes() whose only change is the byte budget.
 * Installed conditionally: if the drift guard (below) flagged THIS core version
 * and ASG_L2_FAILSAFE is on, stay on core's default (caps at 200 — degraded but
 * safe and known) rather than run a fork we know has drifted. */
if ( get_option( 'asg_l2_status' ) === 'drift:' . $GLOBALS['wp_version']
     && defined( 'ASG_L2_FAILSAFE' ) && ASG_L2_FAILSAFE ) {
    // Known-drifted on this core version → leave core's generator in place.
} else {
    remove_filter( 'sanitize_title', 'sanitize_title_with_dashes' );
    add_filter( 'sanitize_title', 'asg_sanitize_title_with_dashes', 10, 3 );
}

function asg_sanitize_title_with_dashes( $title, $raw_title = '', $context = 'display' ) {
    $title = strip_tags( $title );
    // Preserve already-encoded octets through the cleanup below.
    $title = preg_replace( '|%([a-fA-F0-9][a-fA-F0-9])|', '---$1---', $title );
    $title = str_replace( '%', '', $title );
    $title = preg_replace( '|---([a-fA-F0-9][a-fA-F0-9])---|', '%$1', $title );

    if ( seems_utf8( $title ) ) {
        if ( function_exists( 'mb_strtolower' ) ) {
            $title = mb_strtolower( $title, 'UTF-8' );
        }
        $title = utf8_uri_encode( $title, ASG_SLUG_BYTES );  // core hard-codes 200 here
    }

    $title = strtolower( $title );

    if ( 'save' === $context ) {
        // Turn non-breaking spaces, en/em dashes and slashes into hyphens.
        $title = str_replace( array( '%c2%a0', '%e2%80%93', '%e2%80%94' ), '-', $title );
        $title = str_replace( array( '&nbsp;', '&#160;', '&ndash;', '&#8211;', '&mdash;', '&#8212;' ), '-', $title );
        $title = str_replace( '/', '-', $title );
    }

    $title = preg_replace( '/&.+?;/', '', $title );          // strip remaining entities
    $title = str_replace( '.', '-', $title );
    $title = preg_replace( '/[^%a-z0-9 _-]/', '', $title );  // keep only slug-safe chars
    $title = preg_replace( '/\s+/', '-', $title );
    $title = preg_replace( '|-+|', '-', $title );
    return trim( $title, '-' );
}

/* LAYER 2 DRIFT GUARD — self-test the fork against core's live implementation.
 * remove_filter() only unhooks sanitize_title_with_dashes(); the function stays
 * callable, so we use core's CURRENT code as a live oracle and assert our fork
 * still agrees on SHORT inputs (where neither byte cap engages — the only thing
 * the fork changed). Any divergence == core altered the cleanup logic and our
 * copy has drifted. Runs once per core version; shouts, and can fail safe. */
add_action( 'admin_init', 'asg_guard_layer2_drift' );

function asg_guard_layer2_drift() {
    $ok      = 'ok:' . $GLOBALS['wp_version'];
    $drifted = 'drift:' . $GLOBALS['wp_version'];
    if ( in_array( get_option( 'asg_l2_status' ), array( $ok, $drifted ), true ) ) {
        return;  // already settled for this core version
    }
    if ( ! function_exists( 'sanitize_title_with_dashes' ) ) {
        return;  // core refactored it away — no oracle to diff against; the fork
                 // still runs as a standalone copy (it needs no removed function).
    }

    // Deliberately SHORT fixtures so neither length cap fires — any difference is
    // pure cleanup-logic drift, not the byte budget.
    $fixtures = array(
        'الذكاء الاصطناعي',
        'عاجل: تطورات «مهمة» اليوم',
        'Mixed عربي + English — dash',
        'foo/bar &mdash; baz',
        'UPPER   multiple   spaces',
        '%d8%a7 pre-encoded octet',
    );

    $drift = array();
    foreach ( $fixtures as $f ) {
        $core = sanitize_title_with_dashes( $f, $f, 'save' );
        $ours = asg_sanitize_title_with_dashes( $f, $f, 'save' );
        if ( $core !== $ours ) {
            $drift[] = "in=[{$f}] core=[{$core}] ours=[{$ours}]";
        }
    }

    if ( $drift ) {
        $msg = "[Arabic Slug Schema Guard] Layer-2 DRIFT on WP {$GLOBALS['wp_version']}: core "
             . "sanitize_title_with_dashes() no longer matches our fork — re-sync the copy.\n"
             . implode( "\n", $drift );
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) && function_exists( 'wp_mail' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug Layer-2 drift: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        update_option( 'asg_l2_status', $drifted, true );  // autoload — the fail-safe reads it every request
        return;  // do NOT cache "ok" while drifted
    }
    update_option( 'asg_l2_status', $ok, true );
}

/* LAYER 3 — DE-DUPLICATION (optional)
 * _truncate_post_slug() also caps at 200, but only when a slug COLLIDES and needs
 * a "-2" suffix — rare for unique headlines, and it isn't filterable. If you need
 * >200 bytes even on collisions, take over uniqueness here. Most sites skip this.
 *
 * add_filter( 'pre_wp_unique_post_slug', 'asg_unique_post_slug', 10, 6 );
 */

/* TRIPWIRE — verify + alert after every core update
 * This only detects and alerts: it restores the COLUMN, never bytes already
 * truncated. Treat any revert as an incident — restore from backup. */
add_action( 'upgrader_process_complete', function ( $upgrader, $extra ) {
    if ( isset( $extra['type'] ) && 'core' === $extra['type'] ) {
        delete_option( 'asg_schema_sig' );  // force a re-check on the next admin_init
    }
}, 10, 2 );

add_action( 'admin_init', function () {
    if ( get_option( 'asg_schema_sig' ) === ASG_SCHEMA_SIG ) {
        return;  // fast path: already verified since the last update
    }
    $reverted = asg_reverted_columns();
    if ( $reverted ) {
        $msg = '[Arabic Slug Schema Guard] Column(s) reverted: ' . implode( ', ', $reverted )
             . '. Long slugs were truncated — restore from backup and check 404 logs.';
        error_log( $msg );
        if ( defined( 'ASG_ALERT_EMAIL' ) ) {
            wp_mail( ASG_ALERT_EMAIL, 'WP slug schema reverted: ' . wp_parse_url( home_url(), PHP_URL_HOST ), $msg );
        }
        return;  // do NOT cache "ok" while broken
    }
    update_option( 'asg_schema_sig', ASG_SCHEMA_SIG, false );
} );

function asg_reverted_columns() {
    global $wpdb;
    $reverted = array();
    foreach ( array( array( $wpdb->posts, 'post_name' ), array( $wpdb->terms, 'slug' ) ) as list( $table, $column ) ) {
        $len = (int) $wpdb->get_var( $wpdb->prepare(
            "SELECT CHARACTER_MAXIMUM_LENGTH FROM information_schema.COLUMNS
              WHERE TABLE_SCHEMA = %s AND TABLE_NAME = %s AND COLUMN_NAME = %s",
            DB_NAME, $table, $column
        ) );
        if ( $len && $len < ASG_COLUMN_LEN ) {
            $reverted[] = "{$table}.{$column} (now {$len})";
        }
    }
    return $reverted;
}

/* WP-CLI — `wp asg verify` for cron-based monitoring */
if ( defined( 'WP_CLI' ) && WP_CLI ) {
    WP_CLI::add_command( 'asg verify', function () {
        foreach ( asg_reverted_columns() ?: array( 'ok' ) as $row ) {
            WP_CLI::log( 'ok' === $row ? 'Schema OK — both columns at VARCHAR(1024).' : "REVERTED: {$row}" );
        }
    } );
}

This is the kind of problem that never shows up in a tutorial. It lives where
WordPress internals, MySQL's storage rules, Arabic character encoding and SEO all
overlap, and it only reveals itself at the worst possible moment. It's also the
territory we work in every day — keeping Arabic publishing fast, multilingual and
unbreakable on WordPress, right through to AWS at scale.

If you run a WordPress publication in Arabic and want it to survive its own
updates, let's talk.

Further reading

• dbDelta() and the dbdelta_create_queries hook
• Trac #36748 — the TEXT/BLOB downsize protection that VARCHAR never got
• sanitize_title_with_dashes() and _truncate_post_slug()
• upgrader_process_complete hook