In this post, I would share a quick overview of the tonics architecture, note that there are so many things to share about this project, I am only doing a quick overview as a way to warm up, so let's get right into it.
Everything is an App
In Tonics, everything is an app or module or extension, they all mean the same thing, the only difference is, anything called Module would usually contain suites of features and they are usually native to Tonics while App is generally third-party extensions.
An example of a Module is the Post Module while an example of an App can be a Table of Content extension (like the one on this page).
The goal of Tonics is to make everything as modular as possible even assets shouldn't be left out, they all should be self-contained in their respective modules (there is more to this), this way, you only use the modules you want to be included.
What does this mean for Tonics update?
As I previously said, everything is self-contained, this means when there is a bug in the Post Module, and an update is provided to fix the bug, you only update the Post Module without having to update everything, however, the update mechanism would check if an Update is available to the Core Module and if it is, it updates the Core as well, this is so things don't break when a Module uses a new function in the Core Module.
Built-in Itself
Thanks to the Field Module, 90% of the Modules are powered by the awesome Field builder, meaning the U.I of Tonics is mostly written in itself, the good thing about this approach is the promotion of a consistent user interface, and if you are building an app or extension for Tonics, you can leverage the Field To build Fields quickly, and if you want custom functionality that isn't covered by the Field Builder, you can either submit a request for inclusion, if this is something that can't be included, then you can build an extension for the Field.
Here is a quick preview:
Here is another preview of the Field in action, the below video is a demo of how OEmbed works in Tonics:
Learn more about Field Modules
Say Goodbye to Shortcodes
[shortcode][/shortcode]
Does anyone hate that nonsense above?
I don't know about you, I personally hate using shortcodes to include dynamic content, this is my experience using WordPress back then (WordPress has blocks now which I suppose is a replacement for shortcodes).
Fortunately, in Tonics, you get to use Fields directly in the Editor, for example, to add a Table of Content to your post, you click on the Field Manager, under Tools, you select and choose the Table of Content, then you insert it, easy peasy.
To preview the Table of Content, you click on the preview button, this way, you get a live preview of the Table of Content.
Here is a quick demo:
This approach to dynamic content in the Editor is really powerful and there is a lot you can do with this.
What do you get if the Table of Content extension is uninstalled? You get nothing, keeping everything clean and nice.
Note: There are still one or two good use cases for shortcodes, for example, if Tonics doesn't want to include the rich editor in some Fields sections, I think adding support for basic shortcodes is a good idea with the exception that the shortcodes would only be provided by the Core.
Say Goodbye To Link Rot
I am still suffering from a huge number of link rots in my old blog, I had to build an extension to manage that while migrating to Tonics, called Tonics 404 Handler.
Here is the problem, post slugs are hard to get right most of the time, and you'll constantly want to change them either to reflect the title or to keep it short.
The issue with constantly changing post slugs are:
- Dead link in the places you've shared the post
- You lose backlinks when your link is inaccessible
- You might cause frustrations when someone refers to your post which is inaccessible due to a slug changes
Well, I fixed that, each post or category has a unique slug I.D hash, whenever a post is created, a new slug I.D is attached to that post, when someone is visiting the post URL, the slug I.D would be used to get the post information, if that doesn't exist, we fall back to the post slug.
What this means, is Tonics handles automatic redirections for old post slug titles eliminating any possible link rot, you are welcome 😊.
An example is this URL page, try to delete part of the post slug, and hit enter. You'll notice it automatically redirects you to this page, Tonics doesn't really care about the post slug, it only becomes a concern when the unique post slug i.d can't return any info, then Tonics tries to see if it can use the post slug as a fallback.
Robust Job and Scheduler Manager
Tonics comes bundled with a robust job and schedule mechanism, Jobs in Tonics are simple tasks that can be prioritize.
A job is expected to be a short burst task, it is quick and shouldn't take time.
An example of a job is when you forget your admin password, and you send a reset mail request, the thing that carries out the request is the Job, the moment you push the forget button, the Job is pushed into a queue and is waiting to be run, other examples are post publish notification, event notification, etc.
The Scheduler on the other hand is also a type of Job but unlike a job that is short burst, a scheduler is a...
- long running task,
- They may or may not take time,
- Can be scheduled (you can specify the time you want it to run, e.g on a certain Day, Month, Year, etc
- Can run in parallel, for example if you are processing a million newsletter, you can parallelize it by sending 100 mails in 5 separate fork process at the same time, in other words you are sending 5 x 100 (500 mails at a go)
- Can be nested, when Task A is done -> run Task B -> run Task C, etc
- Can be prioritize
- and many more features.
An example of a schedule job is App update, Purging Old Session, Deleting Temp Files, Sending Mail and any other Long running task.
The good thing is that the job and scheduler can be started by running only one single command, that's all that is needed.
Media Manager (API & Event Driven)
The problem with the existing media system is that they are not API Driven, don't promote modularity, lack an event system, and encourage link rot.
I fixed this with the Media Module in the following way:
- API Driven: Since I want it to be language agnostic, I implemented it using Vanilla JavaScript with sophisticated design patterns. So, as long as whoever is implementing the interface conforms with the interface methods you can add an additional drive system, e g your local folder, Dropbox, GDrive, etc. By default, it works with the Local Drive and Dropbox
- Events: The event system ensures the media system could be extensible, so, it has events support. For example, if you want to attach a play icon when an audio file is loading, you hook into the AudioFileEvent, likewise, if you want to hook into other events.
- Link Rot: This is API specific, the way I fixed it for the local drive API was to generate a unique hash for each file, based on the relative path coupled with a random number prepended. This way, moving, renaming, and editing a file shouldn't affect the unique id.
- Resumable: Imagine living in a country like Nigeria (my country) where electricity is unstable, you would want something that can survive an outage, Fortunately, Tonics Media Manager has an inbuilt file resumption, you can literally complete the upload on a different device (when your other device is offline or when uploading is abruptly interrupted due to power outage or network issue) as long as the files you are uploading is the same.
Here is a demo of me moving videos from the image folder to the video folder:
In summary, the media system is extensible (you can use multiple cloud storage, hook into events, and even create events), moving files from one folder doesn't break a media URL, likewise as renaming files and editing files also doesn't break the URL, in essence, you can move things around without worrying about link rot, you are welcome once again 🤗
Domain Specific CMS
Tonics is domain-specific, which is one of my goals for this project. If you are a blogger there are a couple of specific features you'll want, and if you are selling music, there are also some features you'll need.
With Tonics, you get different Modules and Apps depending on your domain, this way, you only use what you need.
Note: I am still working on some Modules for some domains, but due to lack of funds, it has been hard to accelerate the development, so, I am currently stucked as to how I can get funds to accelerate the development, please reach out to me at devsrealmer@gmail.com or olayemi@tonics.app
Domain Channels
Reddit channel: https://www.reddit.com/r/tonics/
If you are on discord, I have created several channels for different domains, so, join the ones you are interested in:
- AudioTonics: This channel is dedicated to people that are interested in selling audio files or beats, so feel free to talk about tools or features you would like to get for your audio website.
- Writonics: Dedicated to the blogging domain suite of Tonics, so, you can discuss anything blogging-related or tools you'll like to see for your blogs.
- AffiTonics: This channel is dedicated to the affiliate domain suite of Tonics, so, you can discuss anything affiliate website-related or tools you would like to see for your affiliate website.
- Others: Send me a dm on discord.
Theme Has a More Defined Scope
My goal with Tonics is to make myself and other users less reliant on Theme doing everything which is why I made it Domain Specific, you get every tool for your domain. Theme would only act as a decoration to beautify your website, nothing more. Another interesting thing about Tonics is that you can use several Themes at the same time, you might wanna use a specific Theme for your blog page and use another Theme for your landing page.
Open-Source Or ?
There is no point in not making this project free, how do I market it to my people in Nigeria that they would have to pay for a CMS and then pay for Domain, Hosting, e.t.c. Doesn't make much sense.
However, I still need a way to fund this project somehow, the codebase is over a million lines of code, while I can single handedly handle it, as it is well architected, the current situation in my country frustrate the pace of the project, even if people contributes to the project, without a steady fund for the contributors, it might just become another abandonware.
So, until I can think of how to monetize it, it would remain free but not open-source, so use at your own risk. If you have an idea on how to overcome this issue, please contact me by using my email or any of the channels above.
The project is sitting here: https://github.com/tonics-apps/tonics
Opinionated
The main goal of this project was to build a music or audio CMS for buying and selling audio for me and others interested but somehow I ended up with a General Multi-Purpose CMS.
Tonics is Opinionated in the sense that:
Each Domain is NameSpaced
Each Domain is namespaced, for example, the Post Module URLs are all under the following path /posts/..., and the category URL are under /categories/..., so there is no way you can change the permalink like in WordPress.
A full post URL looks like so: ex.com/posts/b8dcf4985e5ee586/post-title and a category URL would like ex.com/categories/b8dcf4985e5ee586/cat-name.
There is a reason for that structure which is another article entirely, the short answer is structuring the permalink that way promotes separation of concern, prevents slug clashes, makes link rot prevention easier to implement, makes slug easier to change without a cascading update, and many more.
So, a Track module might have its URL like: ex.com/tracks/b8dcf4985e5ee586/track-title, and so on. Well, all this is done to avoid shooting myself in the foot.
Vanilla All The Way Down
The trend is to use a Framework for a project of this level and to be honest, that is fair. The second rewrite of Tonics was done with a Framework but I want to understand every detail of this Project, I want to be responsible for the Core part which gave rise to the third rewrite, and since I am confident with the project I think it was time to start using it.
The advantage of the Vanilla approach is that I am in control for the most part, and I can design it the way I see fit, hey, it's not perfect but it works.
Feature Packed
This is not really opinionated because you can easily delete features you don't want, nevertheless, Tonis is packed with good defaults, and if your domain falls within the scope of the domain I am working on, then you should get a toolbox packed with what you would ever need to flourish your domain project.
Support & Funding
If you want to support or fund, please reach out, I am open to collaborations.
What Modules or Features Do I have Left To Build?
- Comment Module
- Payment Module ✔
- Newsletter Module
- Polish The WordPress migration tool (Unnecessary as each Module should have its own import feature) ✔
- and other little bugs
Conclusion
The above is just the tip of the iceberg, I have so many things to share but I'll do it one step at a time, so, this concludes a quick overview of Tonics, see you later.