extensions.typo3.org issueshttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues2022-04-04T17:32:47Zhttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/368Smarter default sorting2022-04-04T17:32:47ZMathias BrodalaSmarter default sorting## What do you suggest?
It would be really useful if the default sorting of extensions upon search was a bit smarter. This means that properties really relevant to humans should have a higher weight:
* number of downloads
* date of las...## What do you suggest?
It would be really useful if the default sorting of extensions upon search was a bit smarter. This means that properties really relevant to humans should have a higher weight:
* number of downloads
* date of last update
* number of supported TYPO3 LTS versions
* (possibly more)
This is slightly related to #168 but aims at the default sorting.
## Why?
Users should get a useful suggestion for their searches. It is safe to assume that anyone who actually searches by terms instead of directly opening the detail page of an extension doesn't really know the most common and proven solutions.
## Add an use case
A [search for *registration*](https://extensions.typo3.org/?L=0&id=1&tx_solr%5Bq%5D=registration) currently yields the following result:
1. `registration`
2. `agency`
3. `agency_tt_address`
4. `sf_event_mgt`
5. `slub_events`
6. `sf_register`
7. `autobeuser`
8. `sr_feuser_register`
9. `dated_news`
10. `femanager`
11. ...
You can clearly see the mixed "quality" of the search results. The top hit is `registration` due to the exact name match but it's probably the extension most unlikely to solve the issue at hand since it is alpha, outdated and officially does not support any TYPO3 version. Instead `femanager` and `sr_feuser_register` should be the top hits, the number of downloads support this assumption.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/257Extension Installation Workflow2022-04-04T17:34:23ZThomas LöfflerExtension Installation WorkflowSuggestion:
* Make a dropdown instead of a download button
* Rename it to `Install via`
* In the dropdown there are these options: `ZIP file`, `T3X file` and `composer`
* When clicking one of the option there will open a modal with the ...Suggestion:
* Make a dropdown instead of a download button
* Rename it to `Install via`
* In the dropdown there are these options: `ZIP file`, `T3X file` and `composer`
* When clicking one of the option there will open a modal with the installation How-Tos (currently as collapsables)
* In the background the file will be downloaded (if ZIP or T3X)
* When clicking on `composer` the `composer require <package>` command will be displayed
* In the version history the composer command will be appended with the versionBackloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/203Display number of downloaded in list page2021-02-15T18:22:54ZJainish SenjaliyaDisplay number of downloaded in list pageDisplay number of download extension in list page. SO user can identify easily which extension are mostly usedDisplay number of download extension in list page. SO user can identify easily which extension are mostly usedBackloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/198Why use big boxes when a list does a much better job?2021-02-15T18:22:52ZChristine RocheltWhy use big boxes when a list does a much better job?First show an overview, then detail on demand.
The new repository wastes a lot of space. Why use big boxes when a list does a much better job?
Please show relevant information like number of downloads, last update...
A "list by" funct...First show an overview, then detail on demand.
The new repository wastes a lot of space. Why use big boxes when a list does a much better job?
Please show relevant information like number of downloads, last update...
A "list by" function would also be helpful: List by
- Number of downloads
- TYPO3 Version
- Relevance
Thank you for your work.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/196Layout suggestions2021-02-15T18:22:47ZpixeldesuLayout suggestionsThe entire layout and sizing of the website feels way too large. _(on screens that are not high resolution/retina)_
It fills the entire screen width for certain device widths (`.container-fluid`) and the headings chosen for the card-tit...The entire layout and sizing of the website feels way too large. _(on screens that are not high resolution/retina)_
It fills the entire screen width for certain device widths (`.container-fluid`) and the headings chosen for the card-titles are way too large as well, wasting a lot of screen space.
Here an example, for a _side-by-side_ view. This first screenshot is the current website as-is.
![Selection_262](/uploads/232478dbb288a2749ea0d86dadec084a/Selection_262.png)
And this is a locally modified version (with Chrome DevTools) just to narrow down a lot of things.
![Selection_263](/uploads/dd907cf63ab30d6e6c3c0b417a812cbf/Selection_263.png)
_(both screenshots capture exactly the same viewport, just from different tabs, no tricking with zoom-levels here :smile: )_
**What I changed:**
* Switched out the `.container-fluid` that a huge part of the site used, replaced it with just `.container` instead.
* Replaced all card headings with `h3` instead of `h2` and all subtitles with `h5` instead of `h4`
* _I also adjusted the padding of the TYPO3 logo, just to properly line up the navigation with the container_
These are not too significant changes to the site layout, but they already make a huge difference compared to what there was before.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/190list view: one record for row2021-02-15T18:22:48ZAlex Tuverilist view: one record for rowhi good work.
On my opion the list view of tha main page, where the latest extension are listed, should be simplified, with only one record for row, like in the previous repository.
This should be made with a new LINK (column or row disp...hi good work.
On my opion the list view of tha main page, where the latest extension are listed, should be simplified, with only one record for row, like in the previous repository.
This should be made with a new LINK (column or row display).
thank you very much for your work.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/186List view missing info #downloads latest upload2021-02-15T18:22:53ZEdward LenssenList view missing info #downloads latest uploade.g. https://extensions.typo3.org/
In this view I am missing info like #downloads and latest upload. When you search for an extension with many results, this will help you to select the right extension for you.
This would be great fil...e.g. https://extensions.typo3.org/
In this view I am missing info like #downloads and latest upload. When you search for an extension with many results, this will help you to select the right extension for you.
This would be great filter options too for future.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/170A much slimmer List-View - One row per Extension2022-04-04T17:34:23ZTorben AschmonsA much slimmer List-View - One row per Extension## What do you suggest?
Make the List much slimmer.
Maybe like:
**EXT-Name** - EXT-Description - EXT-Version/State - Target TYPO3-Versions - Update-Date
Just one row per extension.
## Why?
To have a better and faster overview over mor...## What do you suggest?
Make the List much slimmer.
Maybe like:
**EXT-Name** - EXT-Description - EXT-Version/State - Target TYPO3-Versions - Update-Date
Just one row per extension.
## Why?
To have a better and faster overview over more extension.
## Add an use case
I want to take a look over the recently updated extensions. With a more slimmer List-View I can see more extensions on one sight. So I can scroll through the extensions and see more extensions.Backloghttps://git.typo3.org/services/t3o-sites/extensions.typo3.org/ter/-/issues/156Search results are too big2021-02-15T18:22:51ZFedir RYKHTIKSearch results are too big## What do you suggest?
I would like to suggest to make optimization of search results output and to show at least 10 search results on one page. Google is good example. We could show 5 results x 2 columns.
![image](/uploads/8946f4cadc8...## What do you suggest?
I would like to suggest to make optimization of search results output and to show at least 10 search results on one page. Google is good example. We could show 5 results x 2 columns.
![image](/uploads/8946f4cadc8661634284c3e7719e35ed/image.png)
![image](/uploads/13e4f009786316cce5417efa5fe450c9/image.png)
## Why?
Users hates to scroll to find information.
## Add an use case
At the moment even on 1900x1280pxpx screen we could have only 4 results. Very hard to find the good extension in such way.
![image](/uploads/3dc0bc921f39fd0ad58262d630e9196b/image.png)Backlog