Skip to main content

3. Case study: one Article, six image sources

Joomla's own com_content Article is a good stress test, because a single article can reference images through six genuinely different mechanisms:

  1. Intro Image — images JSON column, key image_intro
  2. Full (Main) Image — images JSON column, key image_fulltext
  3. Link A — urls JSON column, key urla (Article's Links tab; a link field can point directly at an image or document asset)
  4. Link B — urls JSON column, key urlb
  5. Link C — urls JSON column, key urlc
  6. Images embedded in the body — <img> tags, srcset, inline CSS url(...), etc., anywhere inside the introtext/fulltext HTML the editor produces

Using the Custom Analyzer Builder, sources 1 through 5 are each reachable — but only as five separate Custom Analyzer definitions, since each definition is limited to one column/JSON-key. That already means five separate rows per article showing up across the audit screens, rather than one clean "Article" entry.

Source 6 is different in kind, not just in count. No number of Custom Analyzer definitions can reach it, because the Builder has no HTML-parsing mode — it can only read a value that's already a path, never scan a blob of rich-text HTML for embedded references. That gap is exactly why plg_mat_content exists as a coded plugin: its extractRefsFromHtml() method DOM-parses introtext and fulltext for srchrefpostersrcset, and inline-style url(...) references — something no amount of Builder configuration can replicate.

The actual shipped plg_mat_content plugin handles all six sources from one coded plugin, in one method chain, and reports every image an article references as fact records tied to a single owner — the article itself — with metadata.source_field distinguishing which of the six sources each reference came from.