Currently, a default Template is loaded which does not allow for much (backend, user friendly) customisation.

For starters we should add a more robust API and a way to easily create custom templates.
Going forward (but not in this release milestone) a Page Builder Extension should be created similar to TukuToi Template Builder we've made for CP.

For this milestone:

• robust but simple API provided for Template developers to create their own templates easily.
• robust but simple fallback template provided (as is currently available)
• robust but simple routing templates (single, archive, search, 404 and home)

While the database structure for it is present as well as the UI to create users and roles, and we can even add roles to a user, uhleloX at this moment neither controls User Roles (it plain simple assumes every user to be an admin), nor does it allow to lock front end user creation or make those by default a very low role.

This needs to:

• have a default check for the user role and make only the first ever created user a super admin, all other users created after, should be of low role and then be managed by admins
• add checks internally and externally for user roles when accessing code and data

currently uhleloX doesn't check for security when accessing files directly.

This means, while you can't access a Dashboard or publish a post since every file is somehow interconnected and directly accessing generally fails in a fatal for missing code, the malicious user still can access those files. That should be impossible.

It's easy enough to avoid that by defining a constant somewhere after session is open and valid, then each file should check if that constant is defined or not.

I thus introduce X_ADMIN for this. If set, the admin is loaded and it is loaded by a valid user. If not set, the admin is not loaded and accessing the file should be impossible.

SonarCloud detected that the cURL connecting to api.uhlelox.com does not check the certificate, thus making it potentially vulnerable to Man in the Middle attacks.

While that's not a big deal, since we verify the signature on download, we still should verify it.

We can take inspiration from WordPress for this.

The idea is to allow users to insert a shortcode (something like [shortcode_identifier shortcode_attribute="shortcode_value"]) in their Text editors (or per function in the Templates/Extensions) which then will display data as determined by the shortcodes PHP code.

For example, a ShortCode could be used to display the current users's description, and all the users would have to do is insert the ShortCode in the editor, instead of crafting PHP or hardcoding the information.

The hooks API is basically the only part that is not native to uhleloX (it is inspired (and mostly copied) from WordPress).

What needs to happen here is that all add_ and did_ and apply_ and do_ hooks should be changed into add_event and do_event or something like hook() and add_hook().
This involves A) a complete review of current code and B) a rewrite of the current classes for hooks.

From the WordPress influence I got, I used slug in the database for what in reality is a UNIVERSALLY UNIQUE IDENTIFIER (UUID).

"slug" really is an animal. It doesn't describe what it really is, namely a unique value that identifies our item apart of the classic id.
Thus, rename this to UUID and refactor all code to listen to the UUID instead.

Currently User Passwords are properly encrypted when we create an user from the Front end.
However when editing a user in the backend the encrypted value of the password is shown in the editor and no way to "reset" (add/chnage) the password in actual plain text is available.

This needs to:

• have an input that is populated by default with the users's password (hidden)
• allow users to add new users with new password
• allow users to change their own or others passwords

WordPress for example has had a long standing issue of Hostile Install/Config Takeovers.

When a user installs WP on their servers and abandons the install without completing it, a third party can call up setup-config.php and complete the install.

uhleloX should avoid this natively, both when installing it, but also when setting up users.
Possibly, the same technology should/could be used to verify users when logging in.

Proposed solution:

• create a simple .txt file in the install that holds (currently one) SHA256 hash of a passphrase the user defines prior to upload the package to the server.
• the user has to save that SHA256 hash in the text file
• the user is then prompted to insert his/her passphrase during install and user creation
• that passphrase is then encoded with the same algorithm and compared to the stored hash. If the hash does not match, the process is aborted.

The user currently can create his/her hash with tools like https://emn178.github.io/online-tools/sha512.html, we could also offer that as a "download safe package here" option, yet, that would theoretically allow the server owner to store both passphrase and generated hash, and then scan the web for the hash value in the text file and thus match domains against generated hashes. Fort this reason, it is probably best to leave the hash generation to the end user, so they can choose to use any tool, inclusive terminal, to generate their hashes.

Most important of all things software is updating it.

uhleloX as of now has no update mechanism, at all, other than manual overwrites.

Provide a update mechanism that allows the following:

• check for updates
• pull updates by the click of a button

This should be done for core

As probably the extensions at some point should become independent entities (even if bundled in the initial core package), I'd assume those shouldn't be included in this logic, but as we are at it, we should consider allowing the update of single core extensions, or, just pull them (core extensions) together with main.

Currently user has to manually set several necessary settings, extensions, templates, and so on after installing uhleloX

This should be automatic.

Settings
Slug: x_site_url, Value: https://domain.tld (your site URL)
Slug: x_upload_max_size, Value: 999999999 (value in bites defining max upload file size)
Slug: x_active_template, Value: uhlelox-template (unless you have a custom template, use that temlate's slug)
Slug: x_field_type_mugshot, Value: img (this is a dynamic setting defining the input type of a field in edit screen. Setting slug can be x_field_type_{field_slug}, value can be img [image input], owner [select2 with users])
Slug: x_field_type_ownert, Value: owner (this is a dynamic setting defining the input type of a field in edit screen. Setting slug can be x_field_type_{field_slug}, value can be img [image input], owner [select2 with users])

Extensions
Slug: x-ck-editor, Status: active (activates the CK Editor on edit screens)
Slug: x-media-browser, Status: active (activates a media browser in the Editors)
Slug: x-file-robot, Status: active (activates media editor)

Templates
Slug: uhlelox-template Status: active (activates the CK Editor on edit screens)

Relationships
Slug: user_role, Entity_a: users, Entity_b: roles
user_page: 1 entry connecting user ID 1 to role ID 1
roles: 1 entry with a new user role owner