Statamic Markdown Table Laravel Package

Getting Started

• Treat 1.0.0-beta as an initial evaluation release. Before installing, check the package’s composer.json for Statamic, Laravel, and PHP constraints, then read the README and CHANGELOG for the exact fieldtype handle, config keys, and rendering expectations.
• Install with Composer using beta stability and pin the version in composer.json/composer.lock:

  composer require vendor/statamic-markdown-table:1.0.0-beta
  

  Prefer an exact beta pin over a floating ^1.0@beta constraint until the package is stable.
• Look first at:
  • the addon service provider and fieldtype registration
  • the published config/views, if any
  • the README’s blueprint and template examples
  • resources/views or rendering classes if the addon ships a renderer
• First use case: add the fieldtype to a simple Page or Article blueprint, enter a small Markdown table in the Control Panel, then render that field in a template through Statamic’s Markdown pipeline.

Example blueprint addition, using the fieldtype handle documented by the addon:

handle: markdown_table
field:
  type: markdown_table
  display: Table

Example Antlers rendering:

<div class="prose table-wrapper">
  {{ markdown_table | markdown }}
</div>

Implementation Patterns

• Keep the field as Markdown source and render it through a single partial so table markup and wrappers stay consistent:

  {{ partial:components/table :content="markdown_table" }}
  

  Inside the partial, render the Markdown and wrap it in a responsive container:

  <div class="overflow-x-auto">
    {{ content | markdown }}
  </div>
  

• In Blade, use Statamic’s modifier chain or your application’s CommonMark renderer rather than manually converting pipes:

  <div class="prose overflow-x-auto">
      {!! Statamic::modify($markdownTable)->markdown() !!}
  </div>
  

• Use the field in Replicator or Bard sets only if the addon explicitly supports that context. For sets, store the Markdown table in its own field and render through the same partial as standalone usage.
• Add a small validation or editorial rule for required header separator rows if editors are entering raw Markdown. Markdown tables fail silently or render oddly when the --- separator row is missing.
• For day-to-day content workflows, prefer the Control Panel field UI over hand-editing Markdown. If the addon provides table editing, CSV paste, or row controls, make that the documented editorial path.
• Write a feature test around the rendered result:

  $response = $this->get('/about');
  $response->assertSee('<table>', false);
  

  This catches fieldtype registration, augmentation, and Markdown rendering regressions early.
• If the addon provides config or views, publish only what you need and version-control the overrides:

  php artisan vendor:publish --tag=statamic-markdown-table
  

  Verify the actual tag from the addon README before relying on it.
• Use CSS targeted at generated table markup (.prose table, thead, td, th) rather than coupling styles to the fieldtype name. That keeps rendering portable if the package changes its template.

Gotchas and Tips

• Beta stability is the main risk. Pin the exact beta version, test upgrades in staging, and read the changelog before bumping. Do not assume semver compatibility yet.
• Composer may refuse the install without an explicit stability flag. Use the documented beta constraint and verify composer.lock records the exact release.
• Markdown tables are limited. Cells generally cannot contain block-level content, multi-line text, or complex nested structures. For rich content, use HTML or a different fieldtype rather than fighting table syntax.
• Escape literal pipe characters in cell content. Unescaped pipes will create extra columns and break the table layout.
• Do not render untrusted Markdown without sanitization. If non-admin users can edit the field, sanitize the generated HTML or restrict rendering to trusted editorial roles.
• Responsive tables need a wrapper. The generated <table> will overflow on narrow screens unless you add an overflow-x-auto container or equivalent CSS.
• Clear caches after install or config changes:

  php artisan optimize:clear
  

  Also clear Statamic’s view/content caches if the fieldtype or rendered partial does not appear immediately.
• Check Control Panel asset publishing if the addon ships fieldtype assets. A missing publish step can make the field appear broken even though the backend is registered.
• If rendering differs between the Control Panel preview and the frontend, compare the exact Markdown renderer and extension configuration. Statamic, CommonMark, and the addon may not use identical table extensions.
• Extension points to look for: publishable config, publishable views/partials, a custom renderer class, or a fieldtype augmentation hook. Prefer overriding a view or renderer over forking the package for minor markup changes.
• Keep a fallback path. Because this is a beta addon, document how to migrate stored Markdown tables to a plain Markdown field or Bard content if the package is abandoned or breaks on a Statamic upgrade.