As such I will also sort them into priority order. That is to say, the first thing listed is the most important and the last thing is the least important.
Furthermore to shed some light on how we plan to release everything as far as timelines. We have divided everything up into three stages. These should help to get things out faster without relying on outside conditions.
1. Theme release: Theme will initially be released as an officially supported theme via .com. It may not be a full 100% final version. A lot of things may be hacked together to make them work based on the current version backend limitations. It will also not be a validated theme as it will completely break all validations rules due to it being structured completely differently.
2. Minor version releases: These will contain improvements to the core that will be necessary to fully support the full capability of the new theme. It may all happen in 3.3 although not likely it may not all be done until 4.0
3. Major version release: This will happen once the backend & frontend finally meet all the requirements to packaging the new theme with a release as well as the new styleguide/editor.
Obviously, the theme itself is priority 1. I will be focusing solely on that. We will be accepting any help from any front-end devs to help alleviate some of the workloads, especially when it comes to JS.
I have broken it down as follows.
1. Initial Code/design phase for individual components
2. Second Code/Design phase/code polishing cleanup
3. Layout Initial/Secondary pass
4. Proper twig linkage for all the necessary template vars
5. Js refactoring for individual components
6. Design changes
7. Extensions?
8. Porting
To understand the following list the term BLOCKER refers to something that completely holds up the theme from being released even standalone
Template System update: (#9 BLOCKER) mrgoldy Pull Request [MERGED]
The template system requires changes so that it checks the necessary folders in the correct order for the bits and pieces of the theme. so
Code: Select all
{% include 'header.html' %}MCP/UCP: (#6 BLOCKER) ticket Dev Team
Currently, the tabs for the MCP/UCP are built via loops; however, these loops are not accessible outside of the MCP/UCP pages which limits the design and layout of the forum. These lops need to be globally accessible on any page. Also, this will require the is moderator var to work globally as well which is currently IIRC does not work on every page (concept: https://codepen.io/hanakin/pen/JraPQv?editors=1100 will work similarly to side menu found here: http://www.codecovers.eu/materialadmin/ ... /dashboard).
JS: (#5 BLOCKER) Dev Team
Complete rewrite of all the JS to include core.js Really all js should be packaged in the all/js folder rather than being a part of core.js There is no reason the ACP should not be able to read from here. All JS needs to be rewritten to modern standards in a modular fashion. This will require a new custom framework(similar to how we are handling all the new CSS in layers) for all js code. All js across both the front-end and back-end ACP.
Search: (#7 BLOCKER) ticket Dev Team
This should be rewritten to combine all search methods into a single interface. possibly function similar to IPBs search in that you can filter. Currently, we have two different search fields on a page. a global search in the header, and a second search in the toolbar above the topic lists and posts. All of this functionality needs to be refactored into a single search interface found in the header of every page. similar to how it is done in every other forum software out there...
Avatars: Dev Team
Currently, this returns HTML from the core. It should instead populate template vars. It also varies inconsistently in the code it returns based on what kind of avatar it is. All we really need is the
path, title, source(ex: "gravatar") to use as a subclass. We should also have a default avatar as well. This could be something as simple as just a standard default image that we load via the template. We also need it to work similar to Facebook and allow editing of the avatar on upload. This is very important as we require a square avatar.PROPOSAL:
- Fix how avatars are displayed:
mrgoldy Pull Request [MERGED] The avatar needs to have three things that can be accessed as template variables. title (custom title), type (image, gravatar), file name if local, src (stored url too the avatar, link for gravatar or local path if not)The template will then contain all necessary html. Not exactly sure on the final html yet but<img class="o-avatar o-avatar-{{ AVATAR_TYPE }}" src="{{ AVATAR_SRC }}" alt="{{ AVATAR_TITLE }}">. It should also return as the src the default if an avatar is not set. path will beall/avatars/ - Create advanced avatar uploading (facebook like): (#4 BLOCKER) mrgoldy, marc Pul Request Like the title suggests an avatar editor similar to the facebook avatar tool.
mrgoldy Pull Request [MERGED]We need a template partial and possibly a method or two to handle rendering the proper icons. To put it simply we want to allow the user to choose between (SVG, font, png) based icons. The partial/method should receive an icon name and type and return the correct code to render that type of icon. This should drastically simplify the inclusion of graphical assets and should be used everywhere across the theme. To include normal icons, forum image sets, and even topic icons (which are currently global in the core and configured in the ACP.) This will require some refactoring of this to function in a way that they can choose an image in either of the three mentioned types. The only requirement should be the same as the method requirements. The icon name and the type. The dimensions should be dictated by the style and not the DB. these should also be moved from their current location to all/imgs/icons. In fact, it may make sense to just move all of the images stuff to all/imgs
Topic Icons/Contact Icons/Rank Images/Smiles/Imagesets SVG Support & More: (#1-3)
Currently, each of these is added via the ACP as raster images. This needs completely overhauled to allow for more appropriate customization and better quality image types ie. SVG. It should work with and utilize the new ICON macro for all of them which is being worked on. (Imagesets are the outlier they just need the capability to use a custom name so instead of
sticky-mine-read you can specify foo-bar in the ACP)ICON SVG CONVERSION PROPOSALs:
- IMAGESETS: hanakin Pull Request [MERGED] Using icon function based on flags in template
- CONTACT ICONS: hanakin Pull Request [MERGED] Using icon function based on contact name in template. Either use the name value as the name for loading a custom svg, or iconify icon, or filter on it to load one from iconify. Probably/currently the later.
- TOPIC ICONS: (#1 BLOCKER) ticket Dev Team Possibly work them the same way that we do the contact icons. Change the ACP to only add a title flag that can be filtered for in the template to add the images via iconify or use as the filename to load an SVG from the SVG folder.
- RANK IMGS: (#2 BLOCKER) Dev Team Possibly work them the same way that we do the contact icons. Change the ACP to only add a title flag that can be filtered for in the template to add the images via iconify or use as the filename to load an SVG from the SVG folder. Probably the latter.
- SMILES: (#3 BLOCKER) ticket Dev Team Merge smiles with emojis. Add a custom emoji section similar to discord for the ones that do not have an equivalent. Currently, there are only three. The last three defaults are in the list. Convert emoji system over to utilize icon function as well so that we can easily add custom emojis. Where custom emojis load SVG files from the SVG folders and the normal emojis use iconify.
BBCODE parser(s): (#8 BLOCKER) Dev Team
Refactor and clean up. Should only pull from one source for what code to render (no more need for template_bitfield) https://tracker.phpbb.com/browse/PHPBB3-15145?, https://tracker.phpbb.com/browse/PHPBB3-11819. Should pull from the template system via bbcode.html to give style authors complete flexibility and control. This means all hardcoded HTML should be factored out of the core into bbcode.html...for example the emoticons. Part two of this refactoring is that the font-size should be refactored to instead just provide the capability to apply header tags. Rather than generic sizes. It should just wrap the text in h1/2/3/4/5/6 tags based on the choice from the dropdown. Lastly by default, I believe the way it renders paragraphs is by use of two
<br> tags. This should instead just opt for wrapping the content in a paragraph tag. for exampleCurrent:
Code: Select all
Creating a new theme for phpBB is a daunting task especially given the small number of individuals on the team and the fact that most of us have day jobs.<br>
<br>
In order to help drive this thing and generate community involvement both in discussions and development, I wanted to put together a sort of outline of what we need to help steer the individual topics as well as provide a sort of table of contents for reference and ultimately a checklist/progression chart.<br>
<br>
Code: Select all
<p>
Creating a new theme for phpBB is a daunting task especially given the small number of individuals on the team and the fact that most of us have day jobs.
</p>
<br>
<br>
<p>
In order to help drive this thing and generate community involvement both in discussions and development, I wanted to put together a sort of outline of what we need to help steer the individual topics as well as provide a sort of table of contents for reference and ultimately a checklist/progression chart.
</p>
This is really its own project and will require its own very in-depth discussion found here However on the surface it will be a hosted service on .com as well as a locally installable companion app. It provides the capability to view all the individual theme components and edit their predefined settings as well as edit the SCSS/TWIG code all from the editor. A good starting point might be http://atomicdocs.io/, but it should also allow for scaling to test responsiveness similar to (http://styleguide.devbproto.com/styleguide/#4). It will also allow for the capability to add/delete components for a new theme. All without ever having to leave the editor if you so wish. It will require PHP(maybe)/jquery(maybe)/VUEJS/SCSS/TWIG(or equivalent)/GULPJS/NODEJS.
API: (#100) Nicofuma
This one is way far out and not related to the current iteration of the theme at this time, but needs to be on everyone's radar. Eventually to really strive to stay current with the modern web we need to look into completely overhauling things dealing with the DB to work from a core API. One that can eventually be leveraged by the front-end to build and run the app via something like angular, react, or VUEJS.
