github-mirror/discourse
2
0
Fork 0
mirror of https://github.com/discourse/discourse.git synced 2024-12-02 13:59:04 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
e94ab11477
discourse/app/assets/javascripts/admin/addon/templates/plugins-index.hbs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

27 lines
735 B
Handlebars
Raw Normal View History

FEATURE: Introduce DBreadcrumbs components (#27049) This commit introduces the following components: * DBreadcrumbsContainer - The wrapper template-only component, which renders all DBreadcrumbsItem components on the page. * DBreadcrumbsItem - The component that registers a LinkTo for the breadcrumb trail. The breadcrumb > trail > will show based on the order these items are rendered on the page. * BreadcrumbsService - Manages the DBreadcrumbsContainer elements on the page via DBreadcrumbsContainerModifier. * DBreadcrumbsContainerModifier - Handles registering DBreadcrumbsContainer elements with the BreadcrumbsService and deregistering them. For now, we will only use these breadcrumbs in the admin section of Discourse, and this initial commit only uses them in admin/plugins. This is heavily based off of https://github.com/Bagaar/ember-breadcrumbs, but will be further modified for our needs.
2024-05-20 12:25:54 +08:00
<DBreadcrumbsContainer />
DEV: A different approach to breadcrumbs (#27365) Really fully authored by Jarek, I only made the PR :) The `DBreadcrumbItem` and `DBreadcrumbContainer` components introduced in 1239178f496cba5d864adb7c118b17902b8b72dc have some limitations, mainly that the container has no awareness of its items, so nothing that requires positional knowledge can be used. This is needed to use `aria-current` on the last breadcrumb item, see https://www.w3.org/WAI/ARIA/apg/patterns/breadcrumb/examples/breadcrumb/. We change `DBreadcrumbItem` to always be a link, removing the need for `LinkTo`. Then, we introduce a service to keep track of containers and items (since all items are rendered into all containers) and make the item itself responsible for registering to the service, and introduce the needed `aria-current` behaviour. --------- Co-authored-by: Jarek Radosz <jradosz@gmail.com>
2024-06-07 09:31:46 +08:00
<DBreadcrumbsItem @route="admin" @label={{i18n "admin_title"}} />
<DBreadcrumbsItem @route="adminPlugins" @label={{i18n "admin.plugins.title"}} />
FEATURE: Introduce DBreadcrumbs components (#27049) This commit introduces the following components: * DBreadcrumbsContainer - The wrapper template-only component, which renders all DBreadcrumbsItem components on the page. * DBreadcrumbsItem - The component that registers a LinkTo for the breadcrumb trail. The breadcrumb > trail > will show based on the order these items are rendered on the page. * BreadcrumbsService - Manages the DBreadcrumbsContainer elements on the page via DBreadcrumbsContainerModifier. * DBreadcrumbsContainerModifier - Handles registering DBreadcrumbsContainer elements with the BreadcrumbsService and deregistering them. For now, we will only use these breadcrumbs in the admin section of Discourse, and this initial commit only uses them in admin/plugins. This is heavily based off of https://github.com/Bagaar/ember-breadcrumbs, but will be further modified for our needs.
2024-05-20 12:25:54 +08:00
FEATURE: More flexible admin plugin config nav definition (#26254) This commit changes the API for registering the plugin config page nav configuration from a server-side to a JS one; there is no need for it to be server-side. It also makes some changes to allow for 2 different ways of displaying navigation for plugin pages, depending on complexity: * TOP - This is the best mode for simple plugins without a lot of different custom configuration pages, and it reuses the grey horizontal nav bar already used for admins. * SIDEBAR - This is better for more complex plugins; likely this won't be used in the near future, but it's readily available if needed There is a new AdminPluginConfigNavManager service too to manage which plugin the admin is actively viewing, otherwise we would have trouble hiding the main plugin nav for admins when viewing a single plugin.
2024-03-21 11:42:06 +08:00
<div class="admin-plugins-list-container">
{{#if this.model.length}}
<h2>{{i18n "admin.plugins.installed"}}</h2>
<AdminPluginsList @plugins={{this.model}} />
{{else}}
<p>{{i18n "admin.plugins.none_installed"}}</p>
{{/if}}
Support a `url` field in plugin metadata
2015-02-07 07:08:57 +08:00
FEATURE: More flexible admin plugin config nav definition (#26254) This commit changes the API for registering the plugin config page nav configuration from a server-side to a JS one; there is no need for it to be server-side. It also makes some changes to allow for 2 different ways of displaying navigation for plugin pages, depending on complexity: * TOP - This is the best mode for simple plugins without a lot of different custom configuration pages, and it reuses the grey horizontal nav bar already used for admins. * SIDEBAR - This is better for more complex plugins; likely this won't be used in the near future, but it's readily available if needed There is a new AdminPluginConfigNavManager service too to manage which plugin the admin is actively viewing, otherwise we would have trouble hiding the main plugin nav for admins when viewing a single plugin.
2024-03-21 11:42:06 +08:00
<p class="admin-plugins-howto">
<a href="https://meta.discourse.org/t/install-a-plugin/19157">
{{i18n "admin.plugins.howto"}}
</a>
</p>
Add plugin outlet to admin plugins index
2018-06-06 05:47:30 +08:00
FEATURE: More flexible admin plugin config nav definition (#26254) This commit changes the API for registering the plugin config page nav configuration from a server-side to a JS one; there is no need for it to be server-side. It also makes some changes to allow for 2 different ways of displaying navigation for plugin pages, depending on complexity: * TOP - This is the best mode for simple plugins without a lot of different custom configuration pages, and it reuses the grey horizontal nav bar already used for admins. * SIDEBAR - This is better for more complex plugins; likely this won't be used in the near future, but it's readily available if needed There is a new AdminPluginConfigNavManager service too to manage which plugin the admin is actively viewing, otherwise we would have trouble hiding the main plugin nav for admins when viewing a single plugin.
2024-03-21 11:42:06 +08:00
<span>
<PluginOutlet
@name="admin-below-plugins-index"
@connectorTagName="div"
@outletArgs={{hash model=this.model}}
/>
</span>
</div>
Reference in New Issue Copy Permalink