Migration of a site from MODX to 1C-Bitrix

Website Migration from MODX to 1C-Bitrix

MODX Revolution is a popular developer CMS. Flexible template system, Snippets, Chunks, TV variables — all this allows building practically any site. But when business requires full online store with 1C integration or corporate portal with CRM — MODX starts limiting. Switch to Bitrix solves the task, but requires understanding both systems.

MODX Data Model

MODX Revolution stores content in several key tables (default prefix modx_):

• modx_site_content — all site resources: pages, articles, folders. Fields: id, pagetitle, longtitle, alias, content, introtext, parent, template, published, publishedon, createdby, createdon, menutitle, description, content_type, uri.
• modx_site_tmplvar_contentvalues — TV variable values for resources: tmplvarid, contentid, value.
• modx_site_tmplvars — TV variable definitions: name, caption, type, elements, default_text.
• modx_site_templates — templates.
• modx_users, modx_user_attributes — users.
• modx_categories — snippet/chunk categories (not content).

For stores on miniShop2: msProduct, msProductOption, msCategory, msOrder, msOrderProduct — these are extension custom tables.

Page Tree

MODX builds site as resource tree. Each resource — potentially a page. In Bitrix this concept doesn't exist: site structure determined by physical files in directories + structure management in admin.

Static MODX pages (corporate site, "About", "Contact" sections) transferred two ways:

1. As Bitrix pages — create PHP files in directories, content written via $APPLICATION->SetPageProperty() and components.
2. As iblock elements — if many pages and they're homogeneous (e.g., blog).

TV Variables → Iblock Properties

Template Variables (TVs) — analog of iblock properties in Bitrix. Read all TVs from modx_site_tmplvars and project corresponding properties:

Content Transfer

Script reads modx_site_content and for each resource of needed type:

1. Determines iblock section by parent (recursively build sections tree beforehand).
2. Collects TV values via JOIN modx_site_tmplvar_contentvalues → modx_site_tmplvars.
3. Creates iblock element via CIBlockElement::Add().

Field uri in MODX — ready URL-friendly address of resource. Save it as element CODE and use for 301-redirect formation.

Images. In TV variables of image type stored path like /assets/images/photo.jpg. Copy files to Bitrix server, register via CFile::MakeFileArray().

miniShop2 → Bitrix Catalog

If MODX had miniShop2:

• msProduct (JOIN to modx_site_content) → Bitrix catalog iblock elements.
• msProductOption — product options (color, size) → product offers.
• msCategory → iblock sections.
• msOrder / msOrderProduct → b_sale_order / b_sale_basket.
• Prices from msProduct.price → b_catalog_price with needed price type.

Chunks, Snippets and Templates

Chunks (modx_site_htmlsnippets) and snippets (modx_site_snippets) — MODX template engine code (Smarty / Twig or native PHP). They don't transfer automatically. All functionality implemented anew via Bitrix components. This is most time-consuming stage if site used complex snippets (pdoMenu, pdoPage, FormLister etc.).

SEO

MODX with friendly_urls enabled builds URL by uri field. If site used AliasListing — URL could include full tree path. Collect old_uri → new_url mapping and write redirects.

Timeline

Without miniShop2, migration from MODX is relatively fast — data structure is clear, TVs map well to iblock properties.