Future Changes

[dtdesign]

Disclaimer: This is a rough list of things that may or may not be considered for the next major release. Things will get added, removed or postponed till eternity - do not take anything here for granted.

Things listed here are not guaranteed to be implemented EVER.

• Simple Comment Integration for Page Classes Integrating comments on a page requires a bit too much repetitive PHP code, it should be off-loaded into a trait to reduce copy&paste. – @BurntimeX
• Efficient DOM-Element Creation Creating even simple DOM elements is rather cumbersome because of the rather verbose element API, with elCreate() being merely a wrapper around document.createElement(). We could integrate hyperscript that has proven to be both efficient and simple (see preact), in order to reduce the boilerplate-noise created by the native element API. – @dtdesign
• PIP GUI: Required Language Items Certain PIPs require additional language items, for example for objects types based on the object type identifier. It would be useful if such language items could be edited directly as part of editing the entry. – Gravatronics
• Reinstall package via devtools Devtools should support uninstallation and installation of the same package with one click of a button. – Gravatronics
• Simplify Notification System Implementing new notifications is too complex. Possibilities to reduce the complexity:
  • Work the DBO classes directly as most already implement all of the relevant methods and instead of IUserNotificationObjectType::getObjectsByIDs() use runtime caches or object providers.
  • Simplify language items: Only require one language item for titles (which internally handles stacked vs. non-stacked notifications via the {plural} template plugin) and one language item for messages which is also used in the user interface and for emails.
  • An event class for event will probably still be required but it should be simplified by providing default implementations for most methods as current implementations for title and message getters almost only differ in the names of the language items (which could be determined via the object type of the event object and the event name) and the variables made available in the language items. -- Gravatronics
• Mark deprecated methods and fields The use of PhpDoc comments to flag deprecated methods is quite inconsistent and cumbersome, including the lack of a reporting ability. #2798 was an earlier attempt before PHP8's attributes were introduced that appear to be exactly what we are looking for. We should monitor https://wiki.php.net/rfc/deprecated_attribute for a possible built-in attribute in the future. -- TimWolla

Archive

• SameSite Attribute for Cookies (#3593) Evaluate the state of the SameSite attribute for cookies and see if it works without causing side-effects in supported browsers. See https://github.com/WoltLab/WCF/pull/2548 – @dtdesign

• DevTools: Creating new Projects (#2772) Offer to create a new package.xml through a guided process. Maybe even add editing tools that lets the user make changes to the configuration, such as adding dependencies. – @dtdesign

• Flexible Controller Resolution (#2773) Controllers are expected to resolve according to their location, that is a controller provided by an app is tied to the app's path at all times. This makes it quite easy to lookup the controller for a given URL, but prevents controllers appearing at other locations, such as setting the core's landing page to be truely an app's controller, without the need of a redirect. – @dtdesign

• Content Removal Tool (#2716) There are more and more places where user-generated content can exist and it has become quite cumbersome finding every piece to remove it. This can be solved by a central object handler (similar to the com.woltlab.wcf.message-object type) that receives the data from specialized handlers. Eventually this data can be transversed in a worker-style fashion, without exposing too much of the internals behind each type. – @dtdesign

• DevTools: Creating and Editing of PIPs (#2545) Writing PIPs is more or less an annoying task, that requires far too much manual work. Offering a GUI not only eases this process by suggesting the components, but it would also open up the opportunity for inline-help on each element. – @dtdesign

• Generic Template Components for Forms (#2509) Creating forms requires quite a redundant set of HTML tags and template scripting in order to provide a consistent UI/UX. This repetitive task is prone to errors and can easily lead to code duplicates that gradually become out-of-sync when changes are made. – @dtdesign

• More Places to Check User Group Assignments (#2809) Add more places (in all packages) where UserGroupAssignmentHandler::checkUsers() is called to have quicker reactions to changed properties that can be used for user group assignments. – Gravatronics

• Unified File Uploads (#2825) Template logic and server-side processing, e. g. move_uploaded_file() or specifying exact upload strategy classes instead of using a central identifier, cause code being duplicated far too often. A central upload handler could also offer a simple flag to enable image validation and (implicit) resizing. – @dtdesign

• Reactions (#2508) Based on the like system (with internal +1/0/-1 states), but way more flexible and user-configurable. – @dtdesign

• TypeScript/Babel JavaScript Compiler The current JavaScript code is heavily limited to the ES5 standard which is required to support Internet Explorer 11 and implicitly Safari 9/10. This causes us to be unable to make use of newer language constructs that greatly improve the work flow and reduce code, such as arrow functions or async/await. Using Babel we can start writing modern code that is compiled into ES5-compatible code for production use. The only downside of this is that we will no longer be able to expose the original JavaScript code to IE11 and thus debugging becomes even more annoying.

  UPDATE: Investigate if we're able to use TypeScript during the development to enable strict typing and meaningful IDE suggestions. TypeScript is able to output modules that will work with require.js, preserving the backwards-compatibility.

  UPDATE 2: Currently in development: #3543 – @dtdesign

• MySQL 5.6 or newer: FULLTEXT support for InnoDB The search API relies on extra tables that use the MyISAM schema in order to use it's fulltext search index. This is bad for numerous reasons, for example, it duplicates a lot of data, increases the overall complexity and decreases the accuracy of the results to due its internal limits. See #3404 – @dtdesign

• One option per line #4041 Several options in the ACP require different options/values to be written in separate lines. A more "modern" approach could be used (similar to tags). -- Gravatronics