Opened 14 years ago
Closed 13 years ago
#7457 closed bug (fixed)
No batch deleting of unhandled resources
Reported by: | humdinger | Owned by: | deejam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Website/Userguide Translator | Version: | |
Keywords: | user guide | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
On the "Unhandled resources" page I can mark entries by hand and "Delete selection". But if I select "Select all" or "Select matching extention" (after entering e.g. "svn-base") and then press "Delete selection" nothing gets removed, though the checkboxes were marked.
Change History (8)
follow-up: 2 comment:1 by , 13 years ago
follow-up: 3 comment:2 by , 13 years ago
Replying to deejam:
Do you get the confirm dialog, with a list of items to delete?
When I select 5: yes
When I select 10: yes
When I select 15: yes
When I select 20: yes
Since pretty much all files have the extention .svn-base, selecting by extention or doing "Select all" both result in many, many files being selected. In any case, deleting that big number of files does not show a dialog and fails.
It could be the configured size limit of the number of POST data allowed on the server side. That should be visible in the error log. Try using the Select matching extension and make sure that not to many entries are selected (test 5, then 10 etc). If this is the case, the server configuration needs to be changed.
Maybe the server configuration needs to be changed... :)
comment:3 by , 13 years ago
Replying to humdinger:
Replying to deejam:
Do you get the confirm dialog, with a list of items to delete?
When I select 5: yes
When I select 10: yes
When I select 15: yes
When I select 20: yes
Since pretty much all files have the extention .svn-base, selecting by extention or doing "Select all" both result in many, many files being selected. In any case, deleting that big number of files does not show a dialog and fails.
I think the error is the LimitRequestFields in Apache, which is 100 by default. I've e-mailed Niels and told him to check the value of 4 Apache variables and 5 PHP that can affect the behavior of forms.
It could be the configured size limit of the number of POST data allowed on the server side. That should be visible in the error log. Try using the Select matching extension and make sure that not to many entries are selected (test 5, then 10 etc). If this is the case, the server configuration needs to be changed.
Maybe the server configuration needs to be changed... :)
Probably. Let's await Niels reply. Another option is to change the JavaScript to select ~95 each time (or how many you can select and have room for the form data). That is a better solution since it will work if we reinstall the tool later on. Default configuration changes should be avoided.
A third option is to do it using Ajax. Then there should be no limit.
comment:4 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
comment:5 by , 13 years ago
This should hopefully be fixed in b2d7235436cb. I've set the upper limit to 50 checkboxes.
From the commit message:
Fix deletion of unhandled resources where deleting more than 100 caused the server to reject the request. * Fix an undefined error in the javascript causing it to break. * Set the checkbox limit to 50. * Display how many checkboxes where matched, how many where selected and how many there are in total. * On second search, uncheck non-matched checkboxes.
As usual, wait for the next pull by Niels. Let me know if this solved the problem.
follow-up: 7 comment:6 by , 13 years ago
Well, it does work as you describe... But doing a "Select all" or "Select all {extension}" and ending up with only 50 selected items is kinda fraudulent. :)
I guess you can't select really all matches and do the actual deleting in 50 item batches in the background?
Granted, having so many unhandled resources seems to be a very improbable situation. I think us having over 3000 of those resulted from some unintended import.
Can you delete all those ".svn-base" files directly in the database? After those are gone, I'd be fine with a 50 item limit.
PS: Is there a way to see if Niels has already pushed one of your changes to the server? Maybe some version/date info on an admin page?
follow-up: 8 comment:7 by , 13 years ago
Replying to humdinger:
Well, it does work as you describe... But doing a "Select all" or "Select all {extension}" and ending up with only 50 selected items is kinda fraudulent. :)
Well, don't shoot the messenger. As I explained, I think it is a bad idea to change the Apache configuration. So this is what we have to live with. Vincent probably never tested with more than 100 checkboxes, which I can understand.
I guess you can't select really all matches and do the actual deleting in 50 item batches in the background?
No, since Apache would only allow 100 items (I think) in each request. Ajax would work, or sending a text file containing the data. But both are lots of work for little effect.
Granted, having so many unhandled resources seems to be a very improbable situation. I think us having over 3000 of those resulted from some unintended import.
Can you delete all those ".svn-base" files directly in the database? After those are gone, I'd be fine with a 50 item limit.
I do not have access to the server. That complicates things. Also, I think that they are deleted from the database but kept on disk in case you need to undo. Which is good.
PS: Is there a way to see if Niels has already pushed one of your changes to the server? Maybe some version/date info on an admin page?
Not easily, no. Maybe he could send an e-mail to some mailing-list after each upgrade. But that's off-ticket.
If you e-mail me the instructions of what you want to delete, then I can help you. It will not take that long to do and it is a one-time job. I will also e-mail Niels and ask him to manually change to 95, which should be the maximum since there are 5 form inputs (form, 2 buttons and a textbox). I selected 50 because I was certain that it would work. If 95 works, I can create a patch using 95 instad of 50 and also change the Select All button label to something less "fraudulent".
In my word this ticket is now solved. Agreed?
comment:8 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Niels changed manually to 95 and it worked! In changeset ed6b402a77f0 I've also changed it to 95 and renamed the button Select all to Select first 95.
Closing this ticket.
Do you get the confirm dialog, with a list of items to delete?
It could be the configured size limit of the number of POST data allowed on the server side. That should be visible in the error log. Try using the Select matching extension and make sure that not to many entries are selected (test 5, then 10 etc). If this is the case, the server configuration needs to be changed.
Fixed a bug where the Select matching extension would not work if you entered an extension starting with a dot ("."). Changeset 8caa6486a99b, which will be uploaded to the server on the next pull.