We're excited to bring you a small but important update - the introduction of a human-friendly changelog!
We understand that reading through raw git logs can be a daunting task, so we've taken the time to create a changelog that's both human and machine-readable. This new changelog is handcrafted by our team to provide you with a clear and concise overview of each update. We hope you find it helpful!
One week after the v3, we now have a brand new version! It is about twice as fast and makes lots of internal changes:
Due to the ReadyToRun and Multiple themes features, there are some changes that users must be aware when upgrading their sites. More on that later.
Recent DotNet versions allow a hybrid approach between compiled vs JIT compilation. It is called ReadyToRun. It tries to optimize the code converting some into native code and also make some inferences about the JIT optimizations.
The main advantage is speed. It will probably be about 2 times faster. It will also pave the way to further attempt to complete AOT compilation #35 , which would bring even more speed and smaller size. However, it required some changes, specially in the YAML parser, because it needed to avoid Reflection.
BREAKING CHANGE: all page and site settings (YAML) that are not de default variables will be ignored. Only custom data present under
Params:will be kept into your pages. Before, unknown values were automatically placed under Params, even if placed elsewhere.
SuCoS now allow sites to install multiple themes (but still only use one). They will be placed inside a themes/ folder (or overwriting it using ThemeDir variable in the site settings sucus.yaml). It will also allow using nested git repositories and splitting the theme into other remote repositories.
BREAKING CHANGE: until now, the theme data was supposed to be placed in theme/ folder. Now, one must create a themes/ folder and put the theme data into a folder within it, like themes/my-theme
new theme terminal commandYou can now scaffold the theme structure using the new SuCoS new theme command. It will -still- not populate with any generic theme, but it's the plan for the future.
The source code now has CODE_OF_CONDUCT and CONTRIBUTING documents. The first state the expected conduct for everything in the project, from users or maintainers. Respect, tolerance and a bit o humor are a must. The second contains instructions on ways to start contributing and making changes for yourself. Further instructions are in developer section of this site.
When using live server, if the 404 page is hit (non-existing page), the server was raising an exception and crashing.
when calling SuCoS version or SuCoS help terminal commands, it was crashing.
Some changes in the code that do not change the behavior of the app.
.nukeCommands folderv3, finally, is now public:
As I've mentioned in the v2.2.0 post, I forgot to mark the release as breaking change. It was so impactful that I was not able to even update this very site. Now I've decided to mark as a new version, signalling the need of changes of any client site.
SuCoS newsite -o <PATH> will create a simple blank site.
Using containers to build your site is one of many usages of the program. GitLab, GitHub, Netlify and Cloudflare allow specifying the site builder.
The base image will impact in the speed that the provider will download it to build your site. It was never a big size but it exposes the software to potential vulnerabilities.
The new images (now using both Microsoft modified Ubuntu and Alpine) are smaller and have less stuff into them. Win-win. For those that are using the latest, nothing changes.
It's now possible to check all the links of your site using the checklinks command. There are flags to check only internal or external links and to skip any given URL that are problematic. It's useful for the build process, making sure that your site is all valid.
Note
The "internal" flag, that scans the filesystem instead the URL might not work if your site uses Aliases or changes the name of the content.
Hold onto your hats, folks! It's time to celebrate a major milestone - our very own Static Site Generator (SSG) built with C# has officially turned one! As we blow out the candles and sing "Happy Birthday," let's take a moment to reflect on the wild ride that our SSG has been on since its inception on April 1st, 2023.
Our SSG was born out of a desire to test and improve my C# skills, as well as a growing frustration with the template system used by Hugo, a popular SSG built with Golang. I wanted to create a solution that addressed a problem that I was personally facing. And so, the idea of our SSG was conceived!
When it came to choosing a template system for our SSG, I opted for Liquid templates. Their popularity and user-friendly nature made them an ideal choice for our SSG. They provided the flexibility and ease of use that I was looking for, making it a perfect fit for our SSG.
As for performance, DotNet (6, 7, and now, 8) has been instrumental in making our SSG the powerhouse that it is today. The C# team's continued efforts to enhance the performance of DotNet have made it a viable option for performance-critical programs. This has significantly improved the speed and efficiency of our SSG, making it a reliable choice for developers.
As mostly a one-man project, the use of AI was a very important motivator for diving into unknown territory. ChatGPT, Copilot, Bard, Gemini, and Mistral were mainly used to generate test suites, analyze and suggest optimizations in the code, and suggest libraries that might help.
While our SSG has come a long way in its first year, there's still work to be done. In the coming months, I plan to implement key features such as pagination, multi-language, and image manipulation and conversion. My "ultimate" goal is to port my personal blog to our SSG, and I'm confident that these improvements will make that possible.
My wife thought it was an April Fool's joke when I started our SSG. But here we are, a year later, celebrating the first birthday of a project that has grown beyond my wildest dreams. It's been a year of learning, growth, and innovation, and I can't wait to see what the future holds for our SSG.
v2.4.0 is now live.
Here are some of the highlights:
Now the build command is implicit. Also, the --source option is now an argument, so one can call either build or serve and then the path directly. As before, the default is to assume the current path (./). The usage of --source or -s is still possible and will take precedent, for compatibility’s sake.
Now you can build a site just by calling SuCoS.
When something goes wrong in the build or serve processes (and it most definitively, will), the program crashes. Well, we are not fixing anything here, but at least print the sh*t in a very delicate manner!
Program updated to .NET 8. Faster by consequence. Unless you are using SuCoS as a library, nothing changes.
After some weeks of development hiatus after the sad passing of my dog Mage Merlin, I'm back developing my juice. 2.2.0 was supposed to be 3.0.0 due the disrupting changes for the page resources. I hope anyone using the system found their way.
Anyway, let's try to summarize:
You have three bundle types:
index.md or _image.md. They are the hub and all other files in the folder will be considered as its resources.content/
├── post/
├── my-article/
├── index.md // Leaf bundle
├── image1.png // Page resources
├── articles-list/
├── _index.md // Branch bundle
├── content2.md // Page resources
├── another-article/
├── index.md // Leaf bundle
├── image2.png // Page resources
Resources can be accessed and printed in the templates:
<li>
{% for resource in page.Resources %}
<ul><a href="{{ resource.Permalink }}">{{ resource.Title }} (FileName: {{ resource.FileName }})</a></ul>
{% endfor %}
</li>
You can set the title of the resources and rename the assets directly on the front matter metadata.
ResourceDefinitions:
- src: '*specs.pdf'
title: 'Specification #{{counter}}'
- src: '*.pdf'
name: "pdf-file-{{counter}}"
- src: '*.jpg'
name: "{{title}}-{{counter}}"
title: "{{title}}-{{counter}}"
The results would be:
| Resource file | Name |
Title |
|---|---|---|
| checklist.pdf | "pdf-file-1.pdf |
"checklist.pdf" |
| guide.pdf | "pdf-file-2.pdf |
"guide.pdf" |
| other_specs.pdf | "pdf-file-3.pdf |
"Specification #1" |
| photo_specs.pdf | "pdf-file-4.pdf |
"Specification #2" |
| my-photo.jpg | "posttitle-5.jpg |
"posttitle-5.jpg" |
| my-kids.jpg | "posttitle-5.jpg |
"posttitle-5.jpg" |
Microsoft.AspNetCore, that is going to be deprecated, with System.Net for the live server.Warning
Despite not being marked as a BREAKING CHANGE, it includes a breaking change.
Warning
It was supposed to be published in 2023-08-17.
Despite not being marked as a BREAKING CHANGE, it includes a breaking change.
Due to a familiar problem, the death of (from 3) my dog Mage Merlin, I've basically stopped everything I was developing for weeks. I'm still managing to resume all the stuff. I was working in a feature of Page Resources (embed pictures, PDFs, videos, etc.) into pages. It was incomplete, but I decided to publish the WIP, so users might get any potential new feature.
Each page can have extra content, like image files, video, audio, PDF, and even other markdown pages. They are called page Resources. It's available on Bundle pages (see the 2.2.1 post).
I dedicate this release to my 4-pawns son, Mago Merlin Harigaya Massa 🐕. RIP my boy.
New version live. Simple but it's moving forward! That what matters.
Here are some of the highlights:
Pages now have a Draft variable that can be used to signal content that is still under development. This can be useful for keeping track of work in progress, or for sharing drafts with others for feedback.
To create a draft page, simply add the Draft variable to the front matter of the page. For example:
---
Title: My Draft Page
Draft: true
---
Still writing...
You can then use the --draft or -d command line argument to serve the draft page.
The site variable is now exposed as a top-level variable, so you can access it directly in your templates. This makes it easier to access site-wide variables, such as the title or description.
For example, you could use the site.Title variable to display the site title in your header.
<div>
<h1>{{ site.Title }}</h1>
</div>
We hope you enjoy the new features in v2.1.0!
We're absolutely ecstatic to present to you the fresh-off-the-software-press v2.0.0 release of our platform! This isn't just a bump in the version number or some behind-the-scenes tinkering. No, my friends, this is a revolution for writers and website creators alike, ready to charge up your creative engines!
Let's dive right in and explore these thrilling additions and enhancements:
Our vision has always been a website abundant with vibrant pages. Previously, these pages sprung from markdown with front matter. But we've realized that our code's class Frontmatter was donning many hats, including handling content metadata and calculated properties.
Time for a paradigm shift! Let's call a spade a spade. Front matter will solely parse from content, while Page ascends as the principal entity. We've cleared the clutter by removing an internal "page-lite" class in favor of front matter. Yes, even the system-generated pages like tags now employ front matter to shape the full page.
This reinvention might disrupt compatibility from previous ABI, thus flagged as Breaking Changes and boosting the major version to the groundbreaking 2.
In a nod to all future literary prodigies, our Pages now can bare it all – outputting the text in its raw, untarnished form, free from the confines of HTML and markdown tags. To bask in this authenticity in your template, simply use {{ page.Plain }}.
Also, say hello to the new word count functionality, powered by {{ page.WordCount }}.
As like any other page variable, they are case-sensitive.
Fine-tune your sucos.yaml to include Description and Copyright information, making your website even more enticing to SEO algorithms. Implement these in your templates with {{ page.Site.Description }} and {{ page.Site.Copyright }}.
By default, SuCoS smartly sidesteps pages marked with a past ExpiredDate yaml tag. However, we believe in giving you control. Override this feature by simply setting the -e or -expired flag in the command line.
In our relentless quest to maximize security and performance, we've transitioned most of the code from public to internal. In the C# universe, this means that while our code remains internally visible, it isn't exposed to the public. The only outlier here is our testing suite, which needs access to do its thing – testing!
We've introduced a multitude of optimizations, mainly avoiding thread locking, to serve you a robust, performance-oriented system. Enjoy a smoother, faster experience!
We've pushed the test coverage envelope to now encompass 63%+ of the code, ensuring it stands strong even in rare scenarios. A slew of testing sites has been set up to simulate a wide variety of these scenarios. But wait, there's more to come! Stay tuned.