Platform Serialised Fields Laravel Package

Product Decisions This Supports

• Schema Flexibility: Enables rapid iteration on entity fields (e.g., admin-configurable forms, dynamic attributes) without database migrations, reducing devops friction for non-breaking changes.
• Low-Code/No-Code Use Cases: Accelerates feature delivery for internal tools (e.g., CRM custom fields, reporting dashboards) where schema changes are costly or prohibited.
• Legacy System Modernization: Allows incremental upgrades of monolithic PHP apps by decoupling UI changes from database schema evolution.
• Build vs. Buy: Justifies not building a custom serialization layer for simple key-value storage needs, especially if the OroPlatform ecosystem is already adopted.
• Roadmap Prioritization: Critical for teams maintaining OroCRM or similar platforms where entity extensibility is a core requirement.

When to Consider This Package

• Adopt if:

  • Your app uses OroPlatform or OroEntityExtendBundle (this is a dependency).
  • You need runtime-configurable fields (e.g., admin-defined attributes) without schema changes.
  • Your team prioritizes developer velocity over strict data integrity (serialized fields bypass validation/constraints).
  • You’re working with legacy systems where schema migrations are risky or slow.

• Look Elsewhere if:

  • You require strong data validation (serialized fields bypass Doctrine constraints).
  • Your use case needs queryable/searchable custom fields (consider Eloquent accessors or JSON columns instead).
  • You’re not using OroPlatform (this is tightly coupled; alternatives like Laravel’s json column or packages like [spatie/laravel-activitylog] may fit better).
  • The last release (2016) is a dealbreaker—seek actively maintained alternatives (e.g., [laravel-json-attributes]).
  • You need multi-language/multi-tenant serialized fields (this lacks built-in support).

How to Pitch It (Stakeholders)

For Executives: "This package lets us add custom fields to our entities (e.g., CRM attributes, reporting metrics) without slowing down deployments with database migrations. For example, our sales team could define new ‘deal stages’ via the admin panel—no dev work required. It’s a force multiplier for internal tools, especially if we’re already using OroPlatform. The tradeoff? We’d need to accept that these fields won’t be queryable like traditional columns, but the speed to iterate outweighs that for our use case."

For Engineering: *"OroEntitySerializedFieldsBundle gives us a battle-tested way to store dynamic key-value pairs on entities without schema changes. It’s a drop-in for OroPlatform projects and plays nicely with their entity extension system. Key caveats:

• No validation: Data here is raw PHP-serialized; enforce logic in your app layer.
• No queries: Can’t WHERE or JOIN on these fields.
• Abandoned: Last update was 2016, but the core concept is sound—we’d need to fork or pair with a maintained alternative if this becomes critical. Proposal: Pilot this for non-critical custom fields (e.g., user metadata) and compare performance/overhead to JSON columns or accessors."*

For Developers: *"This is a lightweight solution if you’re already using Oro’s entity extension system. To integrate:

1. Add the bundle to composer.json.
2. Define serialized fields via YAML/XML (Oro’s config format).
3. Access data via $entity->getExtendedField('key'). Watch out: Serialized fields are stored as BLOBs—no indexes, no constraints. Use sparingly for truly dynamic data."*