Only the URL pattern, the base page template, and the source rows differ. Both archetypes use the same SleekRank page group machinery, the same mapping system, and the same caching layer. You can run both groups on the same site without interference.

You can, but most sites keep one page group per topical cluster so the related entries strip stays coherent. Running separate groups for music decade pairs and demographic decade pairs keeps the internal linking tight and the Open Graph images on-topic.

The plugin caches resolved rows but reads new rows on first request. After appending a row, run a delete query on the SleekRank items table and flush WordPress rewrites once. The new URL is live as soon as a visitor or crawler hits it.

Yes. The plugin treats every slug as opaque, so 1900s-vs-1910s works the same as 2010s-vs-2020s. Data availability is the only real constraint. If your source has rows for older decade pairs, the pages render the same way.

Charts work fine. Most teams embed a chart library on the base page and feed it a data URL or inline JSON from the row through a field mapping. The chart picks up the per-row values and renders without any template-level chart code per pair.

Pick the urlPattern early and treat it as part of your site contract. If you have to migrate, the page group config supports redirects, and most teams add a one-line redirect rule per old pattern using a standard redirect plugin.

Add a status or published flag to the row and use a where clause in your data source config to filter unpublished rows. The plugin only generates pages for rows that match, so drafts stay invisible until you flip the flag.

The table block on the base page reads column definitions from each row. Some rows can carry album sales columns, others streaming share columns. The mapping system replaces the column list per row, so the same template serves heterogeneous schemas.