[TODOs/BLOCKERs] New Default Theme/Style Backend Requirments

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.2.x. If you need support for phpBB 3.2.x please visit the 3.2.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Post Reply
User avatar
hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 907
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

[TODOs/BLOCKERs] New Default Theme/Style Backend Requirments

Post by hanakin »

There are several aspects related to the development of a new theme/style and accompanying template system. To better provide clarity and organization to this daunting task. I will be updating this post with the required changes/tasks necessary to move forward, as well as providing links to open tickets/prs and the POC.

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. As 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 different.

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 package 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 the 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: (#1 BLOCKER)
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' %}
would check the current template first if not found then check the all/template folder. it would need to work for both all assets though twig/js/css/svg/png etc...

MCP/UCP: (#2 BLOCKER) mrgoldy, 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 it currently IIRC does not work on every page (concept: https://codepen.io/hanakin/pen/JraPQv?editors=1100 wil work similar to side menu found here: http://www.codecovers.eu/materialadmin/ ... /dashboard).

JS: (#3 BLOCKER)
Complete rewrite of all the JS to include core.js Really all js should be packaged in the all/js folder rather than being apart of core.js There is no reason the acp should not be able to read from here.

Search: (#4 BLOCKER)
This should be rewritten to combine all search methods into a single interface. possibly function similar to IPBs search in that you can filter.

Avatars: (#5 BLOCKER) Lavigor Ticket
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 img that we load via the template. We also need it to work similar to facebook and allow editing the avatar on upload. This is very important as we require a square avatar.

Icons: (#6) mrgoldy Ticket
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 imagesets, 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 img 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 there current location to all/imgs/icons. In fact, it may make sense to just move all of the images stuff to all/imgs

BBCODE parser(s): (#7)
Refactor and clean up. Should only pull from one source for what code to render 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 completely 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 example

Current:

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>
Recommended:

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>
Topic Icons/Contact Icons/Rank Images/Smiles/Imagesets SVG Support & More: (#8)
Currently each of these are 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. (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)
  • Change ACP to accept a filename(no ext), label, type(dropdown containing the following options: iconify, svg, img)
  • It should allow the uploading of an image/file (svg/png | No gifs and No jpgs each of these are vary bad for performance or have rendering/quality issues). IT should place the file in styles/all/imgs/icons as they are all icons! :o
  • It should add all these to the DB
  • It should return an array of all of these to the template so that we can simply call the icon() macro using the values above in a loop to render. Rank image is the acception here we just need to return a single image
  • It should have proper descriptiosn and notes to guide the user in filling these feilds out and how they are used.
NOTE: These could all possibly be handled via a single Asset class? Possibly even add avatars/imagesets/forum-imgs to it not sure? Also no ticket is created yet. Please notify me if you wish to work on it and I will update this page once the ticket is created.

Editor: (#90) Hanakin
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 thier 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.
Donations welcome via Paypal Image

User avatar
hanakin
Front-End Dev Team Lead
Front-End Dev Team Lead
Posts: 907
Joined: Sat Dec 25, 2010 9:02 pm
Contact:

Re: [TODOs/BLOCKERs] New Default Theme/Style Backend Requirments

Post by hanakin »

BUMP Added add Priority #8 All the icons!!!!!
Donations welcome via Paypal Image

CHItA
Development Team
Development Team
Posts: 162
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: [TODOs/BLOCKERs] New Default Theme/Style Backend Requirments

Post by CHItA »

hanakin wrote:
Sun Dec 23, 2018 7:14 pm
BBCODE parser(s): (#7) CHItA
Refactor and clean up. Should only pull from one source for what code to render 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 completely 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.
All of this is fairly straight forward to do on parsing/rendering level as most of this supported by the text-formater. However, the real issue is with how we talk to the text-formater's API. It makes this a bit more difficult, because currently we only have a single pipeline for all text (poll options, posts etc), and for example applying paragraphs to all doesn't seem to be the correct solution (which otherwise would be pretty simple as it only takes an extra configuration call and reparsing all posts again). I'm frankly not sure when I'll have the time to rewrite that part as it is pretty deeply embedded into the code base, so if anyone else wants to pick this up, please feel free to do so.

Post Reply