New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit media files count in media manager #2758
Comments
Releted to #2619 |
The implementation of the #2619 does not modify the search function. So for each browsed page, the search will be called and process every files in the directory. |
+1001 to modify the media manager behavior :)
|
Really need a fix for this media manager, but pagination seems a bit overloaded. We need AJAX loading of small groups of images, and thus cut down the limit of first search return. |
Due to how @nderambure I believe "AJAX loading of small groups of images" is the same as "pagination" here. |
I think pagination as mxbossard describes is a PHP pagination with reloading of media manager each time a click is made. But I may be wrong. Anyway, I hope a fix will be found as this is a real major problem when a wiki has more than 100 images in root namespace (and it still is too much too load). |
The clicking in namespace tree of the media managers uses already ajax.php for retrieving the images of a namespace. So I understand that you like instead of this entire list, to retrieve the list of media in smaller segments by ajax. However, I'm wondering: what is causing the slow user experience? Is it due showing the list in the browser? Or server side, the assembling of the html response? or is it the search action (by |
I think the problem is the slow build of the page which delay js loading of media manager a lot. I wrote a patch to limit the size of the data array manipulated in the search function. If it works I'll submit the patch. For now, only the media manager will use this limit. The purpose is to always display X first media in a namespace or after a search. |
@Klap-in : there is 2 distincts problems that could be solved independantly or together. As @mxbossard said, the initial PHP build of the images array is a huge work for the server. We could retrieve small segments of images as you said, and in top of this, lazy-loading images would be great for bandwith. |
I am in same boat: over 3'000 files in root /media folder of DokuWiki made Media Manager simply unusable because of slow load time. Ironically, the only function I actually need from MediaManager is to delete the current media file, which I open from a wiki page. But slow / long load time for MediaManager effectively prevents this only useful scenario. Long story short I ended up blocking the generation of file list in MediaManager totally: media.php -> function media_tab_files($ns,$auth=null,$jump='') -> commented line Now I can at least use MediaManager to delete the current media file from a wiki page, without suffering slow load time of the MediaManager. Ugly hack, let's see how finding proper solution goes ahead. |
Maybe it is also interesting to test the development version. The development version has some improvements of the Media manager such as lazy loading. Could be that will help your case as well. (https://www.dokuwiki.org/changes, or more detailed https://www.dokuwiki.org/devel:releases ) |
@Raggaer this is the experience for the last release? The development version has implemented lazy loading, which should improve your use case. |
@Klap-in The problem was with the latest stable release. I will try that one locally to see how it improves, maybe an option to hide image thumbs on the media manager could be added too. |
Hi,
We currently have a lot of images in the default namespace. We choose to work like this for multiple reasons, but the loading is now really slow.
The media manager lack pagination, so I checked the source code. Every files in the namespace directory are scanned and media meta informations are gathered in a PHP array and then sent to the client.
I didn't think much of how to paginate results of the search function (https://github.com/splitbrain/dokuwiki/blob/b058d418d940f5ab7eb2cd126767f4bcd6fdd289/inc/search.php#L26). But I think this function would at least deserve a size limit guard which build and return a sized limited array.
By default this size limit guard would be infinite (-1) to not break current implementation. And I could definitely use a limit in media manager plugin to display a max number of media file. The guard could be set to a reasonable value like 1000, because I cannot imagine à scenario where 1000 files need to be searched, but I may be wrong.
Dokuwiki would benefit of this guard by consuming less resources when every files are not necessary, but only first ones.
I can submit a PR to limit the result count of the search function. And another to add a media size result limit configuration in media manager.
The text was updated successfully, but these errors were encountered: