|Creating a PHP 7/8 FUDforum [message #187954]
||Fri, 18 September 2020 13:34
I am working on creating an updated version of FUDforum to be compatible with PHP 7/8, to be object oriented, and have a much more manageable theme system. I want to post here to give details of what I am working on and what I have planned so that the community can make comments, tell me where I might be off base, etc.|
- Separate presentation from business logic - split pages into a model view controller style system.
- Move business logic into proper classes to reduce code duplication and improve maintainability
- Improve database access to be more secure
- Get rid of superglobals to improve security and maintainability
- Implement Twig support <- Done, but not fully tested
-- Add support for composer
-- Add support for twig
-- Add a rendering engine
-- Add support for PHPUnit
-- Add request lifecycle management
-- Replace database connections with new object oriented versions
-- Convert all pages to use a standard layout file and page specific views
-- Begin conversion of public\index.php into application bootstrapper
- Convert business logic to class based system
-- Move logic from page files into classes
-- Move any output mixed into business logic into the view as appropriate
- Localization and SEO
-- Add optional request processor to handle SEO friendly URLs, and generate SEO friendly links
-- Add localization support
-- Add translation support
New Folder Structure
These are new folders to support this structure
DATA_DIR\FUDEngine\Lifecycle - Request and Response classes managing IO
DATA_DIR\FUDEngine\Part - Components of the forum, such as Post and Thread, as well as utilities to generate lists such as PostList and ThreadList
DATA_DIR\FUDEngine\Renderer - Classes related to rendering output, including TwigRenderer and JSONRenderer
DATA_DIR\FUDEngine\Utility - Utilities such as configuration management
DATA_DIR\Page - Page files, moved from WWW_ROOT_DISK\theme\<theme_name>
DATA_DIR\Theme\<theme_name>\template - Template files, such as layout.twig and sidebar.twig
DATA_DIR\Theme\<theme_name>\view - Page views, moved from WWW_ROOT_DISK\theme\<theme_name>
WWW_ROOT_DISK\theme - contains img, js and css folders for theme-specific elements
As I am testing this, I have the version I am working on posted to my GitHub: https://github.com/wigedev/FUDForum/
Third Party Support?
A question for the community, what are your thoughts on implementing support for dependency injection (PHP-DI) or third party logging modules such as Monolog?
Please take a look at my plan and the code-in-progress and let me know what you think!
[Updated on: Fri, 18 September 2020 15:44]
Report message to a moderator
|Re: Creating a PHP 7/8 FUDforum [message #187955 is a reply to message #187954]
||Fri, 18 September 2020 17:19
I like it, but have a couple of questions:|
1. How do we test your version?
2. Will it be possible to upgrade (or migrate) old forums to your version? This is key, as there are a lot of LARGE (and extremely stable) forums on FUDforum.
3. Do you think it might be possible to use the exiting deployment model for Twig themes, where themes are copied (with localization) from the DATA to WEB directories? This may even allow older and newer themes to exist together in the same deployment.
Just a couple of random notes:
1. FUDforum 3.1 is compatible with PHP 7 (but I haven't tested PHP 8 yet).
2. SEO URL's are currently possible with the path_info_SEO theme.
3. Localization is integrated with TranslateWiki - they are committing translations on a periodic basis.
I assume it won't be possible to push your changes to the existing FUDforum repositories (like https://github.com/fudforum/FUDForum/) as your code is a radical departure from the existing structure. Anyway, I'm looking forward to test your version, to see if it can run my forum sites, and if not, if we can port some of it to the main repo.
[Updated on: Fri, 18 September 2020 17:21]
Report message to a moderator
|Re: Creating a PHP 7/8 FUDforum [message #187956 is a reply to message #187955]
||Fri, 18 September 2020 20:03
1. - To test, just check it out from git into the web folder, run `composer install` in that folder to install the dependencies, then edit the GLOBALS.php file with the paths and database settings. If you are using MySQL it should work, if you are using another PDO database it will probably work.|
2. - Yes and no. The forum would work, the URLs would be unchanged, all the data would still be there, but the themes would not be compatible so they would either be reset to the default theme or would need to have a new theme ready to install.
3. - So, I did initially have it following the original file structure, but then I realized that that approach is somewhat counter productive. My end goal is to only have a single copy of each pages code that is completely independent of the theme, and multiple theme-specific view files, one per page per theme. This removes everything that shouldn't be directly displayed to the end user from the public folder, and could still be configured to allow for distributable themes - even a theme marketplace like WordPress has. Also, the ability to create child themes is possible. And, you could have different theme systems side by side. Don't like Twig, put in an HTML renderer. Or a JSON renderer and create an Angular or React front end. Just by changing a single dependency.
1. - Probably saying compatible wasn't right - but I want to take advantage of the improvements in 7 and 8, leverage things like stronger typing in the code. So I am targeting 7.3 right now. I can downgrade to 7.2 if that is preferred, but that is two versions out of date.
2. - This is really one of the key changes. The URL structure will be independent of the theme being used. You would be able to change the URL structure regardless of the theme just by changing the request object.
3. - I can incorporate the TranslateWiki files, or even have the translation system be able to use TranslateWiki or .pot files, or whatever is needed, and just change a single setting to load the appropriate translation. But again, the goal would be to switch from having theme-en-us, theme-es, etc. to having a single theme that can translate its content into any language.
It probably won't be able to be merged in git - at least at this early stage I wouldn't, but rather see how the two align after the next stage of the development. I am sure there will be plenty of things to fix as well, places that I may have missed, etc. This is still Alpha 0.0.1. But at least it is progress toward the final idea.
[Updated on: Fri, 18 September 2020 20:04]
Report message to a moderator