Move over to a different framework

[McTwist]

By moving over to a different framework, we will clear most of the previous issues without having to do anything else. It will also boost performance while making maintenance and installation really easy.

Yes, the biggest issue is the amount of code that currently needs to be changed. Most projects is against doing this kind of change, but due to how difficult it is currently to test, update and deploy the system, it is most recommended to do such a thing to avoid any further issues.

As we are using PHP, I would suggest Laravel. The newest version requires PHP 7.0, so if we do not want to use that, one, we need to use an older version. I've already created an empty branch for this, so just moving over stuff as we go is the best way of doing things for now.

[31547]

perhaps the codebase could be refactored to something such as flask. i was already planning on seeing how to reimplement the site on a private fork anyway, which brought it to my mind.

EDIT:
i was also thinking about implementing a protocol on top of http for clients and servers to communicate. perhaps the site, live-server, and add-on could take advantage of a standardized way of getting and sending information to and from clients. it doesnt seem like theres a standardized way except with http verbs.

[McTwist]

It got some of the same modules as Laravel has. I think it's mixing the structures too much, but I might be wrong and reading it incorrectly.

[31547]

are you talking about how laravel does MVC?
i was thinking that you could split the web/user-facing side up into the api on a flask server, then nginx and static documents which make AJAX requests to the api to fill up everything.
i think that splitting the information and frontend up like this will help with maintaining the project since people more savvy with es6/react/html5/css3 will be better with the frontend and people more savvy with python, password hashing, blockland's servers, whatever will be better with that. the api would be a standard sort of RESTful client.

kinda like this:

- https://blocklandglass.com/{resource}
- https://api.blocklandglass.com/{resource}

or if you don't want to route the api.bla url:

- https://blocklandglass.com/{resource}
- https://blocklandglass.com/api/{resource}

[McTwist]

Well, I haven't tested it before, so I'm not sure the difference.

However, note that the api should not be accessed through https, to make it possible for Blockland to even use it.

We also got this laravel tree that I made a couple of months ago. I haven't been able to pull through some basic yet, so it's just sitting there, waiting for someone to begin some work on it so it can replace the original whenever it's ready.

[31547]

if there were at least documentation for how to access the current API, then work on the laravel branch would probably get started faster. i would start working on it if i knew even how to access the API or data sources, but it's confusing because it appears split up through a million .php files.

perhaps a document or draft for standardizing the functions and organization for glass could be written? that would also help give the project more direction and make contributing easier

[31547]

what is the main demographic of people who actually use blocklandglass in terms of site or client usage? if people use the client more than the site then perhaps it can just be a simple download page for glass and then the api and resources can be focused more on the client.

[McTwist]

There is a document for the move of the site already. The API will stay the same, JSON.

[31547]

okay. thank you.