Opened 10 years ago
Closed 9 years ago
#31729 closed defect (bug) (wontfix)
Customize.php - Request-URI Too Large
Reported by: | FleXoIT | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.1.1 |
Component: | Themes | Keywords: | close 2nd-opinion |
Focuses: | javascript | Cc: |
Description
Hi,
When I click the Appearance > Background (or any other theme customization option) I cannot see neither the LivePreview of theme nor the customization options.
I tried to check the issue in debug mode (F12) and it seem the next issue exists:
Request-URI Too Large 414
Customize.php - Line 307
<script type='text/javascript' src='http://mydomain.hu/wp-admin/load-scripts.php?c=1&load%5B%5D=underscore,customize-base,customize-controls,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-dragga&load%5B%5D=ble,jquery-ui-droppable,backbone,wp-util,wp-backbone,customize-widgets,jquery-ui-tabs,shortcode,media-models,wp-plupload,mediael&load%5B%5D=ement,wp-mediaelement,media-views,media-editor,media-audiovideo,wp-playlist,mce-view,imgareaselect,image-edit,jquery-ui-slider,j&load%5B%5D=query-touch-punch,iris,wp-color-picker&ver=4.1.1'></script>
It seems this is a jquery related issue, but please help me to solve.
Do you need any further information?
Thank you for your help in this matter.
Feel free to get in touch with any further questions.
BR,
T.
Change History (4)
#2
in reply to:
↑ 1
@
10 years ago
Hi,
Check the values here:
http://alcsutdoboz.hu/tech/tester.php
Thanks,
Tibor
Replying to dd32:
Hi,
Can you provide any details about the server configuration? Nginx, Apache, IIS? etc?
Do you have the ability to modify/inspect the server configuration?
What's happening: Your server is configured to only accept a short request, probably ~500 characters long, while WordPress can generate one longer than that.
Most web servers are configured to handle a request size many times larger, ~8,000 is common AFAIK.
In this case, it's really a server configuration that I don't think WordPress should work around, but one that we should keep in mind. We could convert the
load
parameter to be a base64 compressed string, we could encode the params somehow (using numbers to represent scripts, etc) but it's all to solve a problem that realistically doesn't exist on modern servers.
#3
@
10 years ago
- Keywords close 2nd-opinion added
I think this is probably caused by suhosin.get.max_value_length 512
, although the documentation isn't too clear.
Given it's not normally possible to "see" that variable from PHP, I'm not sure if this is something that WordPress can work around reliably.
We could use base64_encode( gzencode( $list ) );
but that's not going to be as supported as our existing format.
Hi,
Can you provide any details about the server configuration? Nginx, Apache, IIS? etc?
Do you have the ability to modify/inspect the server configuration?
What's happening: Your server is configured to only accept a short request, probably ~500 characters long, while WordPress can generate one longer than that.
Most web servers are configured to handle a request size many times larger, ~8,000 is common AFAIK.
In this case, it's really a server configuration that I don't think WordPress should work around, but one that we should keep in mind. We could convert the
load
parameter to be a base64 compressed string, we could encode the params somehow (using numbers to represent scripts, etc) but it's all to solve a problem that realistically doesn't exist on modern servers.