Because this change will be fairly massive (all of the user-accessible files are going to be touched to some extent), it would not make sense to wait until all of the changes have been made before merging. All that will do is result in an incredibly large diff that no one will review, and therefore it will never be merged. Instead, I would propose that we merge in chunks or even merge each controller separately, to allow for readable diffs and give time to test/review individual parts without worrying about other parts. Because the major controller infrastructure is already present, multiple controllers can be made at the same time as each other. The only issue I can foresee is linking from a finished controller to an unfinished controller or vice versa, but we can figure out how to best handle that later.
As we go, of course, we need to be sure to maintain and add new tests so that a greater amount of the codebase will be covered by the time it is merged than is currently covered. I'm hoping that by converting the files to controllers, a lot of the functionality can be put into methods that can then be unit tested so we don't have to always use functional tests, but we'll see.
We will need to include regression route definitions to continue to route old URLs to new ones (such routes will of course only work when URL rewriting is enabled because, otherwise, routes will need app.php in the URL [see next paragraph]).
One dependency that must be sorted out prior to even beginning is the paths issue (in short, it's the difference between URLs that look like
/app.php?controller=topic/1#p124
and URLs that look like /app.php/topic/1#p124
or (using URL rewriting) /topic/1#p124
. If we do not sort this out first, we will be breaking URLs twice (when it eventually does get sorted out), which is not acceptable.I do have an example of a front controller file in my (as of yet unmerged) Post Revision Tracking pull request: here for anyone who wishes to see how it all works.
Before coding actually really begins, I would like to go ahead and propose and discuss URL routes now so we don't have to do so later. As an example, in my post revision tracking PR, I set up the route to be
/post/{post_id}/revisions
. We could, for instance, allow /post/{post_id}
to redirect to something like /topic/{topic_id}#{post_id}
.One thing I would like to mention is that I plan on implementing a URL "slug" (not sure on the proper terminology, but that's what I've heard before) for some of the controllers (e.g. topic, forum, etc.). Basically, it's a completely optional string of text that can be placed in the URL for "pretty URLs", and is entirely ignored by the server. For instance, with a route definition of
/topic/{topic_id}-{slug}
let's say we have a URL like this: /topic/102-phpbb-3-1-release-date
. When the user sees it, they are given some information about what is actually behind the link before they click it. When they end up clicking it, the server uses the topic ID to serve the user the appropriate topic, and completely disregards the slug. As I said, this would be primarily for making the URLs "pretty". Slugs would be generated based on the topic title, converted to all lowercase, and all special characters would be converted to dashes. An example of this can be seen in a currently out of date extension I have been working on here and here. Of course, you would be able to leave off the slug and use the route /topic/{topic_id}
to get to the same topic. This is, of course, up for discussion.Here is a non-exhaustive list of proposed routes from current URLs. I will add more, and I am open to suggestions on how to do it better if you have any input. Note that the query string will still be used for things like pagination and sort options where applicable.
index.php
- index.php => /
- posting.php?mode=post&f={forum_id} => /forum/{forum_id}/new
- posting.php?mode=reply&t={topic_id} => /topic/{topic_id}/reply
- posting.php?mode=edit&p={post_id} => /post/{post_id}/edit
- viewtopic.php?t={topic_id} => /topic/{topic_id} (adding #p{post_id} will still go directly to that post)
- viewtopic.php?p={post_id} => /post/{post_id} (redirects to) /topic/{topic_id}#p{post_id}
- memberlist.php => /members
- memberlist.php?mode=viewprofile&u={user_id} => /user/{user_id}
- memberlist.php?mode=viewprofile&un={username} => /user/username
- memberlist.php?mode=group&g={group_id} => /group/{group_id}
I am not sure how control panels and their modules will be handled at this point because I have not thought it through yet.
Ideally for private messages, for example, we could have something like this:
- ucp.php?i=pm (default) => /messages
- ucp.php?i=pm&folder={folder_id} => /messages/folder/{folder_id} (note: folder_id in this case can be numeric or one of 'inbox', 'outbox' and 'sentbox')
- ucp.php?i=pm&mode=compose => /messages/new
- ucp.php?i=pm&mode=view&p={message_id} => /message/{message_id}
- ucp.php?i=pm&mode=compose&action=reply&p={message_id} => /message/{message_id}/reply
- ucp.php?i=pm&mode=compose&action=edit&p={message_id} => /message/{message_id}/edit
- viewonline.php => /members/online