danpros
[FEATURE REQUEST] SQLite Support
Is your feature request related to a problem? Please describe. I know, I know... HTMLy is a database-less CMS by concept and design... I've been using HTMLy for a long time and love it. BUT...
I do miss relational-db features like full-text search, guaranteed transactional design to ensure data safety in case of concurrent writes (i.e. to one article) and industry standardization, that is - SQLite is SQLite. Every language can work with it and it's databases, most - out of the box. PHP uses PDO that supports SQLite like a charm.
There are alternate PHP CMSes out there, but they lack good Markdown support, or are overly, needlessly complicated in other areas compared to HTMLy.
Describe the solution you'd like I strongly believe extending the CMS to add support for PDO, specifically and only - for the SQLite engine, and an ability to switch in the config - whether to use flat files (as it does now) or an SQLite DB - would be a logical and very welcome step forward for the product.
HTMLy doesn't have to be "database-less" just "because", is if it were a curse. Since who in their right mind would NOT want to use a robust, systems-compatible but also - local, serverless (as in - doesn't need a separate server like MySQL and such) data-management engine to store their data? SQLite was created for use on warships and it's incredibly robust, fast and supported by 99% of shared hostings with PHP.
Describe alternatives you've considered I considered migrating to another CMS purely because my blog is getting bigger and is calling for full-text search. So it's either I implement such a feature using https://github.com/opensearch-project/OpenSearch - which would only solve this one issue, or discuss with you the option of actually making use of the most amazing DB engine out there in SQLite. I know you are familiar with it. I also suspect you are also aware just how cool it is and why Android, iOS and thousands of other systems and OSes make use of SQLite instead of reinventing the wheel.
I did also consider migrating to Wordpress, but it's simply overkill and is full of bugs, 1-day exploits and I'm not a fan, honestly, of using full-fledged WP just for a freaking "no-hassle" blog.
Additional context Again - I'm not suggesting complete switch to SQLite. But as a first step - making the classes that perform operations with data agnostic of what it is they are working with, by abstracting the calls, so that it could either make use of flat files or SQLite (for now, as it would be plenty already) - would be logical and make the CMS so much more robust thanks to the robust way SQLite functions.
As for data migration from flat files to SQLite and back - it's up to you how to approach this if you like the idea. You are already very familiar with how your routines functions. New classes to support migration to/from will be needed, but also could be presented as "for those who know that they are doing", not like "you can switch back and forth willy-nilly" because it's pointless. Or you could provide a guide and some php (or even python?) scripts for those who would want to migrate manually.
In the end, I believe, it would make sense to make a switch to SQLite as the default or at least - provide a choice to the admin upon HTMLy installation: which engine they would want to go with. As well as let them know that switching in the future would require manual migration of data.
Thank you for HTMLy.
For SQLite support, let's see what the future holds.
But for simple full-text search, the latest version of htmly already supports it. It's just a matter of how we develop it to provide the desired search results.
So when we enable full-text search in the config, then every time we add or edit a post, the content will automatically added to content/data/search.json (post_slug => content). You can add posts without editing them in admin/search. Currently, each addition to the index is limited to 40 posts per execution, in the future it should be possible to set it depending on user preferences.
For bulk update, you can create a custom script, glob the folder and add it to search.json. You can also read existing posts index:
$url = 'cache/index/index-posts.txt';
$posts = unserialize(file_get_contents($url));
foreach ($posts as $index => $v) {
// to do
}
HTMLy doesn't have to be "database-less" just "because", is if it were a curse.
I think the point of having a database-less system like HTMLy is that you can literally migrate your entire setup with a copy/paste job. There are other lightweight blog engines out there that provide database support and simple structure for theming and such, so I think it's great to have an option like HTML that hits this specific sweet spot.
Fulltext search - is not working.
- Fresh install of HTMLy. No any custom.
- I Enabled Full text Search
- Using default latest BLOG theme
- Using PHP8.1
Fulltext search - is not working.
* Fresh install of HTMLy. No any custom. * I Enabled Full text Search * Using default latest BLOG theme * Using PHP8.1
Have you added your posts to the index? You have to do this manually after enabling Full Text Search.
I found the issue is on this BLOG theme. If i click the SEARCH icon on top right, then SPACE between TEXTS are not working. But if the search box inside the body, it works. Means, the search form on top right corner is not accepting the SPACEBAR input. Kindly advise for BLOG theme. Tq