Skip to content

Working notes on 1.9 issues

Jump to bottom
Laird edited this page Dec 23, 2022 · 7 revisions

Introduction

This is a list of miscellaneous stuff that needs to be implemented or considered for MyBB 1.9. Following a bunch of that random stuff is the latest copy of the TODO list that Laird was keeping while developing his Develop the 1.9 theme and plugin system PR (#4607).

Feel free to create issues/PRs for these where they don't already exist.

Also note that a separate list (potentially with overlaps) is being maintained in the Community Forums thread 1.9 dev Errors and strange behaviors.

Random stuff

Do we still need the alt_trow() function in inc/functions.php given that we have an alternative in inc/src/Twig/Extensions/ThemeExtension.php?

Do we even need the one in ThemeExtension.php? It's used only once, in inc/views/base/newreply/newreply.twig.

From: https://discord.com/channels/215876847634743296/215876989733568512/990214923911069757

In mycode_parse_img() in inc/class_parser.php, all instances of $alt should be converted to $image['alt'].

PR #4548.

From: https://discord.com/channels/215876847634743296/215876989733568512/990982518662660106

In admin/modules/config/smilies.php: initialise $errors and check with is_dir() (and probably is_readable() too) before calling opendir().

From: https://discord.com/channels/215876847634743296/378987603325747201/992347502827290635

"Url.twig template needs to set name|raw because nesting url img tag together will output img html as text Not just url.twig, any .twig parser template must use |raw for output because stacking other tags will render just html as text"

From: https://discord.com/channels/215876847634743296/378987603325747201/992643656181883032

"There is parse validation error for img tag if you add new line [img]img.png

[/img]

The problem is alt, it must contain str replace for \n and \r"

From: https://discord.com/channels/215876847634743296/378987603325747201/992673267884240906

"[quote]text[/quote] is hard coded instead of using templates like [quote=username]text[/quote], no idea why. If we can customize the quote with username we should be able to customize the one without it... Line 857"

From: https://discord.com/channels/215876847634743296/215877079911104522/1020730741866381483

(This applies to 1.8 as well as 1.9).

Adding a key on the uid column in the awaitingactivation table greatly speeds up queries that otherwise take tens of seconds to run when this table has many entries in it (thousands).

(Again, this applies to 1.8 as well as 1.9).

From: https://discord.com/channels/215876847634743296/215877079911104522/1020795385771470908

"It's worth pointing out that when you manage groups > list all users in a group if you select all users (on the current page) and perform an action... then the admin page goes back to main user list... not the group you were currently working on... So I deleted a bunch of accounts from an undesirable group... that worked except the next time I "selected all users"... well that wasn't users from that group anymore 😦"

(As above).

From: https://discord.com/channels/215876847634743296/215877079911104522/1020796179564482661 including excerpts from the short conversation that ensued.

"when you select multiple users and move around the user list... the forum retains in memory everyone you selected That's a neat feature I guess, but it can be confusing as people usually expect webpages to only interact with stuff currently displayed...

[...]

the forum says "you will do this action on "X" accounts, are you sure you wanna proceed ?

Maybe it could display usernames as a list on that screen, that would pop up more clearly in people's mind maybe ?"

(As above).

From: https://discord.com/channels/215876847634743296/215877079911104522/1020805023002804244 and the ensuing discussion in the next few messages.

Descriptions aren't shown for forum categories on the admin/index.php?module=forum-management page.

TODO list derived from Laird's local copy re the 1.9 theme system

The main stuff

  • Implement theme update functionality (the equivalent/adaptation of Find Updated Templates): append this to the end of the upgrade procedures for both core and original themes, with the possibility to defer. Provide a means of conflict resolution as described in the current version of the spec.

  • Implement the Twig template equivalent of find_replace_templatesets(). Have the find_replace_templatesets() equivalent act only on board themes for current. Later (see "Helpful extras" below) we can support applying to devdist too, either as hard mods or dynamic on-the-fly mods. In that former case, upon attempting to export a theme, warn when those changes have been made for the theme and need be reverted prior to export. Provide a simple means of reverting them. Other working ideas: (a) Have each plugin provide its apply/unapply modification instructions statically in its plugin.js file. (b) Store this data on plugin activation under the storage/ directory, and record with it which themes it has been applied to. (c) Use the stored data to auto-unapply modifications when de-activating a plugin, as well as to auto-apply modifications to the auto-generated board theme when installing a new original theme.

    • When duplicating a theme as a board theme, apply all plugin mods to it BUT only for mods which hadn't already been applied to the theme from which it's being derived (explicitly, such that it has a copy of the modified template).

The miscellaneous stuff

  • [Moved from "main stuff" to here as its main sub-items have already been implemented (and thus are not shown):] Implement install/upgrade procedures for core themes, for original themes, and for plugins. For core, the install/upgrade procedure is triggered by navigating to install/index.php. For original themes and for plugins, it is triggered by uploading a new/updated theme/plugin archive in ZIP format to the ACP's theme/plugin page as appropriate. With respect to themelets, the procedure is as follows:

    • If the stylesheets property has changed from the prior version, flag in derived themelets that it needs updating.

    • Require that the upgrade script is always run so that at least (1) the version stored in the DB is always up to date, so we know which version number to archive the default theme to, and (2) the default theme actually is archived. To ensure that this requirement is met, on every page load, check the version stored in the DB against the version in code, and if they differ, refuse to show the page in question unless it is the upgrade script; for other pages, link to the upgrade script.

  • Implement inheritance-related functionality for purposes of conflict resolution:

    • When breaking inheritance upon saving a theme resource in the ACP, store its inheritance data in resources.json.

    • When editing a resource inherited directly from a plugin, and breaking inheritance, add to the inheritance data in resources.json the version of the plugin on which the resource was based.

    • Ensure that inheritance data is generated when auto-creating board themes from core/original themes.

  • Provide support for DBs other than MySQL in upgrade56.php - right now, MySQL is simply assumed.

  • Migrate away from the specifier syntax implemented for resolve_themelet_resource() to the specifier syntax proposed in the spec.

  • Implement advisory file locking on all files that might be written to simultaneously: Twig templates; (S)CSS files; JSON files; etc.

  • Update if required any ACP reporting modules where the log contents (esp. supplied arbitrary parameters) have been modified in admin/modules/style/themes.php.

  • Drop the $use_themelet_cache parameter to resolve_themelet_resource() (and other functions) given that we no longer cache theme directories.

  • Rather than alternative _key plugin.json properties, provide for this implicitly in the main property, per https://discord.com/channels/215876847634743296/378987603325747201/1001840574313283644

  • Implement core JS support for the "data" attribute of <script> tags which can be stipulated via the attach() Twig function, as per: https://github.com/mybb/mybb/issues/4328#issuecomment-813399129.

  • Auto-add cache-busting ?ver=[num] to jscript files.

  • Fix the commented-out JS files in usercp/editlists.twig and migrate these files to the core theme's resources.json.

  • Migrate the global $plugins variable from pluginSystem to Euan's new HookManager class.

  • When upgrading from 1.8, uninstall plugins which are not compatible, and warn the user that they should be deleted from the filesystem, else when they attempt to upgrade the plugin, an error will occur.

  • Rework the derivations property of theme resources.json, because it currently lists only templates. Instead, store derivation data against each resource under each of the existing stylesheets and jscripts main properties of resources.json, and add a new templates main property, migrating the derivations data there.

  • Ensure that the derivation data in resources.json is correctly set (for (auto)generated board themes) when importing/duplicating themes.

  • Generate and store information about new conflicts with board themes that descend from newly upgraded/downgraded themes (see the corresponding TODO here: https://github.com/mybb/mybb/blob/e1f73aff771bd26425ee9c95cebf4f8afac7dbe7/admin/modules/style/themes.php#L573-L574).

  • When warning about editing an inherited stylesheet, show the name of the theme (or plugin) from which it's being inherited, rather than the codename.

  • Check through admin/modules/style/themes.php for missing hooks, and provide any that are missing.

  • Update the Browse Themes tab in admin/modules/style/themes.php.

  • Investigate whether templates in core.default/acp/templates/base/parser/ are even used, and, wherever they are, replace their use with templates from core.default/parser/, and then recursively delete the (now) unused templates and their containing directory.

  • Support inherited theme properties and stylesheets (via the relevant JSON files) as 1.8 already does, and as we already do for jscript files in 1.9.

  • Check whether plugin's/theme's codename matches its directory when installing/importing.

  • Resolve the redundancy of the MyBB version string being implemented as both the VERSION constant in inc/src/Application.php as well as MyBB::$version in inc/class_core.php.

  • Update the System Health => Check Templates code to handle filesystem templates.

  • Update debug_page() for filesystem templates.

  • In xmlhttp.php, replace the commented-out eval()s with renderings of Twig templates (there don't yet seem to be appropriate existing Twig templates).

  • Move hard-coded language strings in inc/functions_themes.php and elsewhere into a language file.

  • Update copyright notices on all files: 1.8 => 1.9. Update copyright date notice for modded files to 2022.

  • Port the admin/modules/style/template.php file's 'search_replace' action's functionality to 1.9.

  • Rename the storage directory to data per the spec, according to dvz here: https://discord.com/channels/215876847634743296/386813535176622080/1054345230238896158

The "helpful extras" stuff

        $hashDriver = \MyBB\app('hash')->driver($parameters['user']['password_algorithm']);

with:

        $pwd_alg = empty($parameters['user']['password_algorithm']) ? 'mybb' : $parameters['user']['password_algorithm'];
        $hashDriver = \MyBB\app('hash')->driver($pwd_alg);

and then remove the code I've added:

        if (!$result && user_password_needs_rehash($user)) {
            // Support older password hashing in case of upgrading from 1.8.x to 1.9.x
            $hash = md5(md5($user['salt']).md5($password));
            $result = my_hash_equals($user['password'], $hash);
        }

  • Consider whether:

    • We need to (can/should) call check_template() prior to saving templates to the filesystem.

    • To retain support for global templates, potentially through a theme with codename core.global.

    • The fontawesome .js file being loaded from externally in layouts/master.twig should instead be copied and loaded locally.

  • Update the PHPDoc blocks above build_theme_list() and build_fs_theme_select() for the new parameters, and above template().

  • Work out why misc/captcha/post.twig and misc/captcha/register.twig aren't being used, and, if we find a use for them, shift their JS files into resources.json.

  • Add sub-tabs to the stylesheet property editing page.

  • Using Javascript, make the ACP's template listing collapsible/expandable.

  • Add quick link actions in the ACP's template listing to add and/or delete subdirectories (recursively deleting all dirs/files in those subdirectories).

  • When visiting the ACP theme page, check for themes in the staging directory, and offer to install or delete them (indicating whether it appears that they are already installed) as we already do for plugins.

  • Add an "Archive this plugin's current themelet" button to the ACP Plugins page. Indicate to developers that immediately after releasing a plugin version they should click this button on their development installation (offer to automate this when exporting a plugin, which, of course, requires auto-export of plugins - in a similar fashion to the current auto-exporting of themes - to also be implemented). Then, they can go ahead and modify their plugin's themelet on that installation, and the plugin's version number can (when desired) be updated.

  • Consider whether to disable the Twig cache when in development mode.

  • Correct the upgrade message which says "All templates reverted" or something like that when what was actually accomplished was the installation/archiving of the core theme.

  • Stipulate somewhere/somehow that stylesheet names may not begin with ext. - that is reserved for indicating that the stylesheet is inherited from a plugin.

  • Implement JSON file validation functions which check both for the existence of required properties and the non-existence of invalid properties: e.g., validate_theme_properties(), validate_plugin_properties(), validate_plugin_resources(), etc.

  • Remove redundant code and DB tables/columns/etc as necessary, potentially including:

    • Code related to the stylesheet and template DB tables.

      • The file inc/class_templates.php and references to it in inc/init.php.

      • Especially in inc/plugins/hello.php.

    • The import_theme_xml() function.

    • References to update_theme_stylesheet_list(), deprecating the function itself.

    • admin/modules/styles/templates.php and inc/languages/admin/style_templates.lang.php

    • If can confirm that the req_step_error_cssddir language string is never used, then remove it.

    • inc/adminfunctions_templates.php and all references to its find_replace_templatesets() function.

    • All functions no longer used in admin/inc/functions_themes.php.

  • Via a plugin, implement redundancy elimination when archiving themelets via only including resources that have changed since their last occurrence in an archive. Deleted resources can be represented by an empty file with .deleted appended to the resource's filename.

Clone this wiki locally