Increasing the character limit for an HTML property in Bitrix

Why the HTML/Text Property Truncates Content at 63,200 Characters

Developers working with long HTML descriptions in iblock properties eventually hit the ceiling. You paste an 80,000-character article into an HTML/Text property — only half gets saved. No error, no warning, it just silently truncates. This isn't a bug in a specific project or a server quirk — it's a hard-coded limit in the Bitrix kernel.

In the file /bitrix/modules/iblock/classes/general/prop_html.php, for MySQL the limit is set to $limit = 63200. On one hand, this protects against bloated pages and database growth. On the other, for projects where a single property holds a full article, specification, or technical description, it's catastrophically small. Below are three steps to remove the restriction. And an honest warning about why the third step is a compromise.

Step 1. Raise pcre.backtrack_limit

Before touching the database and kernel, make sure PCRE can even handle long text. The pcre.backtrack_limit directive sets the maximum number of backtracking steps for regular expressions. If the text is long and a complex preg_match or preg_replace hits the limit, you'll get PREG_BACKTRACK_LIMIT_ERROR — and the text won't save at all, even if all other limits are raised.

The edit goes in php.ini:

pcre.backtrack_limit = 20000000

A value of 20000000 (20 million) is a reasonable ceiling for most projects. It comfortably covers both HTML parsing and regex operations during saving. If you can't edit php.ini, the directive can be set via .htaccess or in init.php through ini_set('pcre.backtrack_limit', '20000000'). The second option doesn't work on all hosts — it depends on whether ini_set is allowed for this directive.

It's important to understand: pcre.backtrack_limit isn't about the string size in the database, but about regular expression performance. If the text still truncates after the edit, the issue isn't PCRE but the database and kernel limits. Let's move to those.

Step 2. Expand the Column Type in the Database

Bitrix has two property storage modes for iblocks. If the iblock stores properties in a separate table, the values live in b_iblock_element_prop_s{ID}, where {ID} is the iblock ID. Each property is a separate column named PROPERTY_{ID}. For example, for a property with PROPERTY_24 in an iblock with ID 4, the table is b_iblock_element_prop_s4 and the column is PROPERTY_24.

By default, Bitrix allocates the TEXT type (or BLOB depending on the version) for such columns, which in MySQL is limited to 65,535 bytes. For Cyrillic in UTF-8 that's roughly 32,000 characters; for Latin — a bit over 60,000. The 63200 limit in the kernel is tuned precisely to this ceiling.

First, check the current column type and its attributes:

SHOW COLUMNS FROM b_iblock_element_prop_s4 WHERE Field = 'PROPERTY_24';

Once you've confirmed it's text or blob, change the type. For HTML content, MEDIUMTEXT is enough: it gives up to 16 MB, which comfortably covers any description. LONGTEXT (up to 4 GB) is overkill: it hits the MySQL max_allowed_packet limit, which on most hosts is 16–64 MB, and creates risk during replication and backups without real benefit.

ALTER TABLE b_iblock_element_prop_s4
MODIFY COLUMN PROPERTY_24 MEDIUMTEXT NOT NULL;

Important: in the original Bitrix schema, the column is usually declared as NOT NULL. If you don't specify this in ALTER, the attribute resets to NULL, and the schema diverges from what the kernel expects. Check the original definition via SHOW COLUMNS and preserve all attributes: NOT NULL, DEFAULT, comments.

For iblocks with the older storage scheme, where properties live in the shared b_iblock_element_property table, the query is different — the VALUE column changes:

ALTER TABLE b_iblock_element_property
MODIFY COLUMN VALUE MEDIUMTEXT NOT NULL;

Before running ALTER TABLE on a production server, always back up the database. On tables with millions of rows, the operation can take time and block writes. On a staging environment, verify that data isn't lost and the application keeps working.

Step 3. Raise the Kernel Threshold

After expanding the column, the text will still truncate at 63,200 characters because the limit is baked into the PHP code. The file /bitrix/modules/iblock/classes/general/prop_html.php contains the line:

if ($DB->type === "MYSQL")
    $limit = 63200;

Change 63200 to the desired value. If you've set MEDIUMTEXT, it makes sense to raise the threshold to 100000 or higher — the main thing is that it doesn't exceed the actual column capacity. For example:

if ($DB->type === "MYSQL")
    $limit = 100000;

The text size in characters is easy to check in Notepad++ or via wc -m in the console. Cyrillic in UTF-8 takes two bytes per character, so 100000 characters is roughly 200000 bytes, which fits comfortably in MEDIUMTEXT.

Important warning. Editing the kernel is bad practice. On the very next Bitrix update, the prop_html.php file will be overwritten, and the limit will revert to 63200. If the project updates automatically, you won't even notice when the edit was lost — content will simply start truncating again one day. Besides, kernel edits break support: when contacting Bitrix support, the first thing they'll ask is to roll back the changes.

Why You Can't Just Inherit from CIBlockPropertyHTML

The first thing that comes to mind is to inherit from the standard CIBlockPropertyHTML class and override some method responsible for the limit. Usually GetLength() gets overridden because the name hints at length. This doesn't work.

GetLength() returns the actual length of the value and is called only when checking whether a required property is filled. It doesn't set a maximum allowed length — it tells the kernel how many characters already exist so it can determine whether the value is empty. Overriding GetLength() won't remove the 63,200-character limit, because that limit is applied elsewhere.

The limit is baked into the ConvertToDB() method of CIBlockPropertyHTML. That's where the property value is truncated before being written to the database. The second place is GetPropertyFieldHtml(), which restricts the input field size in the admin form. Neither method can be overridden by simple inheritance: both contain the hard-coded 63200 number inside the body, not in a separate method or property.

Bottom line: inheriting from CIBlockPropertyHTML and overriding GetLength() is a dead end. A reader who copies such code, registers it, and waits for a result will get nothing.

The Right Way: A Custom Property Type from Scratch

The correct approach is to create a full-fledged custom property type by implementing all the necessary methods. Bitrix supports this through the OnIBlockPropertyBuildList event. Below is a minimal working example that doesn't claim to replace the standard editor but shows the structure and principle.

<?php

// /local/php_interface/init.php

class CustomHtmlProperty
{
    /**
     * Property type description for the system.
     *
     * @return array
     */
    public static function GetUserTypeDescription(): array
    {
        return [
            'PROPERTY_TYPE' => 'S',
            'USER_TYPE' => 'CUSTOM_HTML',
            'DESCRIPTION' => 'HTML/Text (extended)',
            'GetPropertyFieldHtml' => [__CLASS__, 'GetPropertyFieldHtml'],
            'ConvertToDB' => [__CLASS__, 'ConvertToDB'],
            'ConvertFromDB' => [__CLASS__, 'ConvertFromDB'],
        ];
    }

    /**
     * Displays the edit field in the admin area.
     *
     * @param array  $arProperty        Property metadata
     * @param array  $value             Current value
     * @param array  $strHTMLControlName Form field names
     * @return string
     */
    public static function GetPropertyFieldHtml(array $arProperty, array $value, array $strHTMLControlName): string
    {
        $text = htmlspecialcharsbx($value['VALUE']['TEXT'] ?? '');

        return '<textarea name="' . $strHTMLControlName['VALUE'] . '[TEXT]" rows="20" cols="80">'
            . $text
            . '</textarea>';
    }

    /**
     * Saves the value to the database. No limit is applied here.
     *
     * @param array $arProperty Property metadata
     * @param array $value      Form value
     * @return array
     */
    public static function ConvertToDB(array $arProperty, array $value): array
    {
        return $value;
    }

    /**
     * Retrieves the value from the database.
     *
     * @param array $arProperty Property metadata
     * @param array $value      Database value
     * @return array
     */
    public static function ConvertFromDB(array $arProperty, array $value): array
    {
        return $value;
    }
}

// Register the handler
AddEventHandler('iblock', 'OnIBlockPropertyBuildList', ['CustomHtmlProperty', 'GetUserTypeDescription']);

After registration, a new property type — "HTML/Text (extended)" — appears in the iblock settings. It works like the standard one, but ConvertToDB() contains no hard limit, so text isn't truncated. The database column still needs to be expanded to MEDIUMTEXT — that's a storage-level requirement, not a PHP logic one.

Advantages of the approach:

• Bitrix updates don't touch your class.
• The limit can be changed in one place — ConvertToDB().
• If the standard property needs to keep its original limit, both types coexist.

The downside is that the standard visual editor isn't connected right away — it requires separate code. But if the task is simply to store long HTML without truncation, the example above is enough.

Checklist

1. Check that pcre.backtrack_limit in php.ini is at least 20000000.
2. Determine which table stores the properties: b_iblock_element_prop_s{ID} or b_iblock_element_property.
3. Run SHOW COLUMNS and confirm the column type is text or blob, and preserve the NOT NULL attribute.
4. Back up the database and run ALTER TABLE ... MODIFY ... MEDIUMTEXT NOT NULL.
5. Register a custom property type in init.php instead of editing the kernel.
6. Migrate existing properties to the new type, or accept that the kernel edit will be lost on update.

The 63,200-character limit isn't a random number — it follows from the old MySQL TEXT type limit. Removing it technically isn't hard, but doing it through a kernel edit means planting a mine for the future. A custom property type from scratch takes a bit more time upfront but doesn't break on updates and doesn't require touching /bitrix.

Теги: 1C Bitrix