Is there a maxiumum number of filesets you can use?
Permalink
I am building a VERY large historical archive site for a client with 1000's of images. To organise these images, there are 1220 filesets (yes, 1220). However, we seem to have a problem over this number where new filesets are not associating any images with them.
Selecting an image from the file manager and then ticking the fileset it should be linked with (followed by update button) does not work. When going back into the file manager, the fileset is no longer ticked. We have had no problems up to this point.
Can anyone tell me if they have used this amount of filesets in any previous projects or if there is some sort of limit?
Selecting an image from the file manager and then ticking the fileset it should be linked with (followed by update button) does not work. When going back into the file manager, the fileset is no longer ticked. We have had no problems up to this point.
Can anyone tell me if they have used this amount of filesets in any previous projects or if there is some sort of limit?
Thanks for the suggestion John but we have tested it on latest versions of FF, Chrome and IE and still not keeping any new fileset boxes ticked with existing images. Very weird!
The underlying html dom elements are a multiselect and set of checkboxes. So you could test a quick standalone html page with a 2000 option multi-select in it and a 2000 option checkbox set in it and see what happens in the various browsers.
Just thought of another thing that could affect this.
Apache security settings can limit the number of form elements so that all form elements above a certain limit get truncated from the post request.
Apache security settings can limit the number of form elements so that all form elements above a certain limit get truncated from the post request.
Hi John
We are still continuing to have this issue. We have looked into what you said and we tried changing some settings in the php.ini file to see if this would make a difference. We saw something about increasing max_input_vars in the php.ini file but this did not fix the issue. Is this what you meant when you spoke about the Apache security settings.
We are still continuing to have this issue. We have looked into what you said and we tried changing some settings in the php.ini file to see if this would make a difference. We saw something about increasing max_input_vars in the php.ini file but this did not fix the issue. Is this what you meant when you spoke about the Apache security settings.
No, there is an apache mod_security that says things like 'only allow 1000 fields in a post request' and stuff like that. Any more fields in a post request and it just doesn't pass them through to php. Its purpose is to prevent buffer attacks. However it also produces unfathomable missing data errors when using very long html forms.
Jshannon posted on another thread about a similar issue since I posted the above. I expect he knows a lot more about apache configuration than I do:
http://www.concrete5.org/community/forums/customizing_c5/404-errors...
Jshannon posted on another thread about a similar issue since I posted the above. I expect he knows a lot more about apache configuration than I do:
http://www.concrete5.org/community/forums/customizing_c5/404-errors...
Hi John,
Thanks for your suggestions on this the other week. We don't have mod security installed so that's not the problem.
We can add images to filesets already uploaded but can't update the images to the newer filesets (even if these newer filesets appear higher up (alphabetically) in the checkbox list) which makes us fairly certain that there is a limit in place somewhere. I'm surprised there appears to be no-one else who has encountered this problem, although not many users have probably created over a 1000 filesets! Any other suggestions you have will be gratefully received :)
Many thanks.
Thanks for your suggestions on this the other week. We don't have mod security installed so that's not the problem.
We can add images to filesets already uploaded but can't update the images to the newer filesets (even if these newer filesets appear higher up (alphabetically) in the checkbox list) which makes us fairly certain that there is a limit in place somewhere. I'm surprised there appears to be no-one else who has encountered this problem, although not many users have probably created over a 1000 filesets! Any other suggestions you have will be gratefully received :)
Many thanks.
...further to my previous post, just discovered that it is definitely after the 999th fileset in the list that the problem starts and we can't update images to any other filesets after this number.
I don't have any more ideas at the moment.
There are multi-user sites using concrete5 where picture uploads are allocated by a fileset for each user. If this is a core problem, then I expect such sites would run into a similar issue after user number 999.
You should write this up on the bug tracker and see what the analysis from a core team member is.
http://www.concrete5.org/developers/bugs/...
There are multi-user sites using concrete5 where picture uploads are allocated by a fileset for each user. If this is a core problem, then I expect such sites would run into a similar issue after user number 999.
You should write this up on the bug tracker and see what the analysis from a core team member is.
http://www.concrete5.org/developers/bugs/...
Hi John...we have now fixed this issue. We had to change the max_input_vars config setting on the php.ini file on the apache server. We thought we had increased the default 1000 limit but realised it was still commented out so wasn't working. All filesets working ok now.
Thanks again.
Thanks again.
ie. Could it be a browser thing before it even gets to be a c5 thing?