Move tooling for admin build to assets folder
In this Pull Request we have made some adoptions that will allow users to move the package.json, webpack.config.js and other configurations files to the "assets/admin" folder. This will free up the root of the directory for your own package.json files, scripts and so on.
However, this means that you have to execute "npm install" and "npm run build" in the "assets/admin" folder instead of the root folder if you want to build the admin of Sulu. If you are updating an existing installation you should also move the files as done in this PR in sulu-minimal.
Refactor definition for administation routes and navigation items
Previously it was not possible to adjust existing routes and the items in the navigation created by another bundle. Due to our forms and lists, which allow quite some configuration, it would be preferrable to be able to add more configuration in your own application. For example, adding another button to an existing form, e.g. in the contact form, or adding another sub entry in the navigation, e.g. for the "Settings" navigation item. The latter one was already possible somehow, but felt a bit like a hack, and since we were refactoring the routes anyway, we decided that it should work the same for both cases.
So what we did is introducing two collection classes, the "RouteCollection" and the "NavigationItemCollection". These collection classes are passed to the "configureRoutes" and the "configureNavigationItems" functions, which are replacing the "getRoutes" and "getNavigationItems" functions. The biggest difference is that these functions do not return an array of routes or navigation items, but add them to the previously mentioned collections being passed as the first argument.
The collections also allow for retreival of already added routes or navigation items using their "get" functions, which means they can be edited as well. This way it is possible to e.g. add more navigation items to the settings section in the navigation. The RouteCollection actually holds instances of different RouteBuilder classes instead of the resulting Route.
Easier retrieval of all webspace locales for routes
Also related to the above change is the one in this Pull Request. There were a number of forms, which should have offered their content in all localizations defined in a webspace. This involved a few lines of code, and was copied over multiple places. To avoid situations like this, we have defined another function in the "WebspaceManager", which makes it easier to retrieve the locales defined in all webspaces.
Allow to configure ToolbarActions
Previously they were not very flexible, meaning that as soon as you want to have a different endpoint than in an existing ToolbarAction, you had to implement it completely on your own. Therefore we decided to make these ToolbarActions configurable as well. They can take options now, and these options can be used in the ToolbarAction itself, where they can be accessed by "this.options".
The following example shows how these options can be set. It is copied from our user form, which has a toggler that immediately sends a request to the server to lock or unlock the user. We used to have a separate "sulu_security.lock_user" ToolbarAction for that, just because we had to hardcode some parameters. Now we are using the options on the ToolbarAction instead.
Extension Points for CKEditor
In the "ckeditorPluginRegistry" class you can add any CKEditor5 Plugin you can find. It will then be added to every CKEditor5 instance being created. The "ckeditorConfigRegistry" class is also used by every CKEditor5 instance and takes a function that receives the current config, and returns an object that is shallow merged with the current configuration, and the end result is passed to the CKEditor5 configuration.
The below example shows how to do that with the Heading plugin, although that one is already integrated into our CKEditor5 by default.