✨ Separation of logic: migrating to Astro Theme Provider

[create-issue-branch[bot]]

Original issue description

Is your feature request related to a problem? Please describe.

• The blog route is included with StudioCMS. What if a user wants to use StudioCMS independently of the theming/styling it provides? For example, using StudioCMS as a CMS on an existing website. I imagine most user's of StudioCMS will want to use StudioCMS as a backend for content without extra routes like the blog

Describe the solution you'd like

I would like to see StudioCMS be split into separate packages

1. A core package that provides the core functionality and a dashboard for StudioCMS
2. Official themes (blog, docs, etc) that use the core package as a backend for editing content

This would allow users to use the core package if they want a CMS for their own routes (like a traditional CMS), and use themes if they want to use pre-built routes for a blog, docs, etc.

This separation of packages is a perfect opportunity to migrate towards Astro Theme provider. Astro Theme Provider already has the APIs that StudioCMS needs to facilitate this migration, and it would simplify the integration code.

Describe alternatives you've considered

One alternative is to not use Astro Theme Provider, but continuing with the current structure has some problems:

• The problems I have already mentioned in previous sections
• No reason to re-design and engineer APIs that already exist inside of Astro Theme Provider

Additional context

I am willing to take ownership of this issue. I am looking for opinions/permission before tackling such a large change, I am available to chat if anyone has questions or wants a more detailed explanation than what I can do in text.

closes #50

[Adammatthiesen]

This PR started as a Migration of Front-end data into a separate package, This also began the preparation required to be able to allow future extensibility of the StudioCMS package! The new StudioCMS-Blog package will act as a Blog Integration/Template as well as an example of how someone can extend the abilities of our new CMS!

• The StudioCMS-Blog package:
  • Blog Index page
  • Blog Slug/Route handling
  • RSS Feed
  • New package entry on page creation/editing!
  • Existing Pages now show their package Relationships!
• Major Cleanup and refactoring (including but not limited to a few custom AIK Utilities)
• New Utilities to allow extension of StudioCMS
  • studioCMSPluginList - A Map of StudioCMS Plugins used to register with the StudioCMS Core.
  • externalNavigation - A Map of External Navigation Links used to register with the StudioCMS Core for usage on the Front-end Navigation bar.
  • customRendererPlugin - A Set of Custom Renderer Plugins used to register with the StudioCMS Core to replace the built in Markdown renderer.
• New Example config: (from node-playground)

import { defineConfig } from 'astro/config';
import db from '@astrojs/db';
import node from '@astrojs/node';
import studioCMS from '@astrolicious/studiocms';
import studioCMSBlog from '@astrolicious/studiocms-blog';

// https://astro.build/config
export default defineConfig({
	site: 'https://demo.astro-studiocms.xyz/',
	output: 'server',
	adapter: node({ mode: "standalone" }),
	integrations: [ 
		db(), 
		studioCMS(), // StudioCMS Integration options can be found in `studiocms.config.mjs`
		studioCMSBlog({
			config: {
				title: 'StudioCMS Test Blog',
				description: 'A simple blog built with Astro and StudioCMS',
			},
		}), 
	], 
});

[Adammatthiesen]

@dreyfus92

I'm here still wondering about how are we going to battle test this.

@jdtjenkins and I have been talking a bit about that on the side, where i explained a few ways where we could test most parts of it... the only thing we really can't test is the actual oAuth Authentication, while local users can be tested. Astro DB has the ability to use a "Self-hosted" database, I was thinking lets build a basic testing database to run our tests against using Jumper's playwright idea that he started. We could use the new testAndDemoMode to be able to bypass the NEED for authentication for checking the different page routes to verify that they are indeed being built correctly, and then be able to test against the login api to get a response as well as user creation. Again the only thing i'm a bit stumped on is the oAuth Routes, which cant really be tested easily without things being configured on multiple points for that, but we do have some prep for tests going in place already!

[Adammatthiesen]

!coauthors

[Adammatthiesen]

!coauthor

[github-actions[bot]]

Co-authored-by: Adam Matthiesen <[email protected]>
Co-authored-by: Jacob Jenkins <[email protected]>
Co-authored-by: Luiz Ferraz <[email protected]>
Co-authored-by: Bryce Russell <[email protected]>
Co-authored-by: Paul Valladares <[email protected]>