[02:20:34] [1/3] I made it so you can add `'cssclass' => RequestWikiWizardForm::REST_VALIDATE_CLASS,` in fields added or changed via hook manipulation to enable live validation. With that enabled, it can validate fields immediately per step, using a rest API which validates based on `required` or `validation-callback` for validation and applied it per step, everything else ca [02:20:34] [2/3] n be fully manipulated via the `RequestWikiFormDescriptorModify` hook, and using the helpers in `RequestWikiFormUtils` to add, remove, or modify any field at all on the RequestWiki page. It can basically allow full control via the hook. I added the hook for this purpose of full control when I rewrote the entire extension from scratch, but this expands on it a [02:20:34] [3/3] bit. [02:35:25] CA/UO, can a feature be added to the new CreateWiki form so the eg. 5-10 most popular extensions can be enabled/disabled right when requesting the wiki? [02:39:56] [1/2] I am going to make something similar but I am thinking it will be done as an option afterwards so once you first visit your new wiki, you get a walkthrough of ManageWiki + the option to configure some very important things. My reason being is I want to avoid making people fill out things we don't need for creation so they don't waste time if it is [02:39:56] [2/2] declined. This idea still needs a lot more to work out though + a discussion in the community before it is released. [04:06:05] That's a really good idea. It also has the advantage of being interactive as opposed to a long list of links. [04:18:19] I love that idea. 👀 [05:46:41] I already did basically the same thing https://github.com/wikioasis/spring here but with some tweaks for the wiki discovery stuff we have [05:47:14] Although it's a bit forceful as it pops up every time you visit unless you finish it or dismiss it rather than just the first time and it has no support for users w/out js [05:48:40] What I want will be built into ManageWiki directly probably. At least partly but will also be modular and will only be for the first time, and only for those with ManageWiki rights. [05:49:34] Though Spring seems interesting. [05:50:33] If it's built into managewiki I would probably avoid the weird hacky extension that uses a bunch of hooks lol [05:50:51] Although it does have the ability to import XML dumps similar to createwikiloadout [05:51:46] That will be built into the CreateWiki system for us so that it can trigger immediately upon creation and thus goes a little faster/prevents default main page at all, and other cases. [05:52:24] tbh one of these days I need to actually fork cw and mw and redo them to avoid having to do hacky things to make it work the way we end up using it [05:54:31] CreateWiki is designed so it can be 100% manipulated at every stage already right now via hooks or overrides. Hooks are not fully ideal but the idea was originally to allow providers to hook into it to allow anything to be dne without having to fork it and maintain a full fork of it. [05:55:05] I am going to be fully reworking the entire architecture of ManageWiki at some point also. [05:56:16] I did rewrite ManageWiki practically from scratch but that was more just the code to modernize and servicefy it, but my next changes with rework the entire UI, and architecture to be more modular and other things. [12:50:41] I like to imagine you rewriting from scratch the entire core architecture of managewiki/createwiki one morning because you felt like it [17:29:09] That is exactly what happened the last time I decided to rewrite half our extensions from scratch lol.