# Magento field notes

> EAV migrations, admin routing, payments, product lists, and the kind of debugging that makes operational reality hard to ignore.

Magento work gets real when the product requirement touches EAV data, admin configuration, payment
behavior, product listing UX, and MySQL all at the same time.

These are field notes from that kind of work: short fixes, SQL snippets, extension decisions,
admin-panel gotchas, and the platform details that matter when a commerce system has to keep moving
while the data model fights back.

The common thread is operational: Magento's EAV model, admin configuration, product listing
behavior, payment integration, and MySQL shape all affect whether the team can change a store safely.
Those are not abstract architecture topics. They are the daily work of making a product behave
predictably for customers and operators.

```mermaid
flowchart LR
  A[store behavior changes] --> B[inspect Magento config]
  B --> C[trace EAV tables]
  C --> D[write smallest data change]
  D --> E[test on staging copy]
  E --> F[deploy with backup and check]
  F --> G[document the recovery path]
```

One common change is converting a product attribute from dropdown to multiselect. That means changing
the EAV attribute metadata and copying existing values from the integer value table into the varchar
value table.

```sql title="magento-eav-attribute-shape.sql"
UPDATE eav_attribute
SET
  backend_model = 'eav/entity_attribute_backend_array',
  backend_type = 'varchar',
  frontend_input = 'multiselect'
WHERE attribute_id = 143;

INSERT INTO catalog_product_entity_varchar (
  entity_type_id,
  attribute_id,
  store_id,
  entity_id,
  value
)
SELECT entity_type_id, attribute_id, store_id, entity_id, value
FROM catalog_product_entity_int
WHERE attribute_id = 143;
```

Treat that as a migration: backup first, run against a staging copy, compare row counts, make it
idempotent where possible, and leave a verification query beside the data change.

<Decision title="Treat platform data changes like deploys">
  A direct SQL fix can be the right move, but it still needs a backup, a narrow target, a staging
  rehearsal, and a check that proves the product behavior changed the way the team intended.
</Decision>

Another common product-list change is infinite scroll. The first version of that idea usually sounds
simple: load the next page with AJAX and append the products. The reliable version is more careful:
pagination, filters, analytics, cache behavior, and accessibility are part of the same decision.

```mermaid
flowchart TB
  A[category page] --> B[filters and sort]
  B --> C[AJAX next page]
  C --> D[append products]
  D --> E[update URL and state]
  E --> F[measure findability and conversion]
  C --> G{failure}
  G --> H[keep normal pagination usable]
```

<Tradeoff title="Enhancement must keep the base path">
  Infinite scroll can make browsing feel faster, but the normal paginated path still has to work for
  bots, weak browsers, keyboard users, broken JavaScript, and support links.
</Tradeoff>

That pattern matters after the stack changes: understand the platform's real data model, make the
smallest useful change, and keep the recovery path obvious. Magento is the surface. The principle is
broader.

A lot of good engineering looks like this in the moment. Not a grand framework. A specific fix. A
query you can explain. A route you can reproduce. A feature that degrades cleanly. A note that gives
the next engineer enough context to move without fear.