Page structure allowing new features

[Joduai]

For quite some time I've been thinking about starting this topic.
Current page structure, and the reasons it stays that way have been already mentioned in #718
But with new requests, and ideas adding even small things becomes problematic.
Every possible page option can't be stored in filename, and processing whole file to get the option stored in custom<!-- tag --> is tedious.

How about moving page's options to new file attached to its parent?
For example by generating page ID, saving this ID in page name as an additional parameter, and use this ID for option's filename.
This ID could be even the page's creation date, thus we would get

2024-10-14-19-00-01_tag1_tag2_page-name.md
2024-10-14-19-00-01_options.md (or any other extension)

this way all content stays without changes in future updates, and we get new possibilities with additional page options.
For backwards compatibility, and to prevent data loss, all tags stored in posts files should still be there.
Just to mention <!--t title t--> <!--d description d--> <!--tag tags tag--> <!--image page type header-->
Why? If page's options file becomes corrupted, or has no data at all, htmly would still display all content just like it does now as a fallback, skipping unavailable data from options file.

I'm not sure about the data structure for options file. Probably in json format, maybe xml or a custom one, you name it.
Changing or adding new options to page wouldn't update post file (except currently existing page options like tag, category...) thus it wouldn't have impact on last modification date.

In some use cases data shown on website - like showing blog posts with featured images and excerpts - wouldn't even process the post file, because all data could be taken from options file. Like image/video/quote, excerpt, tags, category, author etcetera.
Even adding an option to pin a page as a featured post on top of the list would be available straight away, although this one option is somehow doable by using tags. But using tags as additional option for missing features creates new problems along solving others.

I asked earlier for custom options for admin panel, similar to adding new fields in the custom settings for using them in templates.
This would open possibilities to create custom page's options by page admins.

Features that were asked and would benefit from this I can imagine right now are

• robots meta tags, allowing to index page or archive it
• enabling/disabling comments
• allowing other editors to edit post
• custom fields per page
• assign different template file to a page

Any thoughts about this whole idea?

[danpros]

Hello,

Yes we should add per post/page options the core, and because of there is no ID than we can use the slug for the ID, example:

// blog post
post_postSlug.json

// page
page_pageSlug.json

// Subpage
subpage_parentSlug.subpageSlug.json

For folder we can put it in example, content/data/options.

[taufik-nurrohman]

It's only a small chunk of additional data, that won't have any visible impact on performance.

But slow to copy-paste.
https://www.quora.com/Why-does-copying-multiple-files-take-longer-time-than-copying-a-single-file-of-same-size

[Joduai]

But slow to copy-paste.

what exactly does copying large amount of small files - being completely out of scope in this thread - has to do with storing couple additional bytes in text files, that would exist anyway?

[taufik-nurrohman]

Export-import large amount of small size data will be problematic in the future.

[Joduai]

ohh, backups are a way different story
didn't dig into htmly backup functions, but all content files are zipped right away
there's no import function, but those who send a bunch of files through (s)ftp instead of unarchiving them on destination place, surely have plenty of spare time. Or do it on purpose ;)

Nonetheless this is still way far from this thread. I already mentioned 2 possible ways. Missing page options files could be just recreated basing on default options set for pages. Or we store everything in 1 file but advance from plain txt to structurized markup. I winder if there's any other possible solution?

[danpros]

Now I'm curious why not storing all useful data in options files, along with title, descriptions and so on?

Because those data (title, description, tags display, post type data, post content) already available in the main post file, the data accessible in $post so we should not add this data elsewhere. If in WP its like putting some of the wp_posts data to wp_options.

Is there any crucial reason why not transforming text file with content into structurized json or xml format?

Due to preference and its convenience. Markdown is widely used so I believe there is no problem using it.

Loving it fully, but one day inevitably this becomes a bottleneck. What then?

With the current data structure it is unlikely that we will experience a bottleneck.

Projects/services/products will focus on a specific niche/utility, and htmly niche is a simple flat-file blog, so the features that are prioritized to be added are features that are usually found on a simple blog in general.

For options and custom fields, we should use 1 option/config file per each post/page.

And to access the options or custom fields, perhaps:

$myField = get_field('field', $post->slug); // Return all field data for this post
$myOption = get_option('option', $post->slug); // Return all options data for this post

$post->field = $myField;
$post->option = $myOption;

We will have $post->field['my_custom_field']; or $post->option['disable_comment']; and so on.