Opened 14 years ago
Closed 10 years ago
#17249 closed defect (bug) (maybelater)
thickbox modal window dimensions are fixed in wp-admin
Reported by: | DreadLox | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.1 |
Component: | Administration | Keywords: | close |
Focuses: | Cc: |
Description
Hello,
When invoking a thickbox modal in wordpress wp-admin, the dimensions of the modal window can't be customized. Because of media-upload.js is replacing the tb_position() function.
This is not needed that way, and media upload modal window size can be set when calling it.
The workaround is rather complicated, please read: http://binarybonsai.com/2010/02/27/using-thickbox-in-the-wordpress-admin/ down to "The Media Manager Horror"
Change History (4)
#2
@
11 years ago
I wanted to use it to display tutorial videos on my new plugin UI but without more width it's not practical.
It seems there is a workaround, possibly...
"I think i found a solution how to change the width, but that's not the real solution.. I steel don't get it why thickbox width is 670px (as u can see in my code (will folow next) the global thickbox width is set like the parsed arg!! ) So the solutins was: tb_show( ed.getLang('m7.popup_title'), '#TB_inline?width=800&height=600&inlineId=mygallery-form' ); m7_resize_thickbox(); jQuery(window).resize(function(){ m7_resize_thickbox(); }); function m7_resize_thickbox(){ jQuery(document).find('#TB_window').width(TB_WIDTH).height(TB_HEIGHT).css('margin-left', - "
Quoted from Stack Exhange:http://wordpress.stackexchange.com/questions/114107/thickbox-width-cant-be-changed-in-admin/137286#137286
#3
in reply to:
↑ description
;
follow-up:
↓ 4
@
10 years ago
- Summary changed from thickbox modal window dimensions are fixed in wp-admin to Link is dead but content can be found in the waybackmachine.
Replying to DreadLox:
That's really frustrating that Wordpress is denying the relevance of such an issue. Thickbox handling in the admin is a *THICK* problem.
Unfortunately, also the link above is dead for quite a time now. I found it on WayBackMachine and want to share the link:
#4
in reply to:
↑ 3
@
10 years ago
- Keywords close added
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from new to closed
- Summary changed from Link is dead but content can be found in the waybackmachine. to thickbox modal window dimensions are fixed in wp-admin
Replying to Manfred Kipfelsberger:
That's really frustrating that Wordpress is denying the relevance of such an issue. Thickbox handling in the admin is a *THICK* problem.
Given that is has been nearly four years since this ticket was opened, Thickbox has clearly not become actively developed again, and only one usage remains in core (plugin install details), I think continuing to use it in any further capacity is indeed a problem. I don't know the history behind why that function is there, so I'm not sure of the ramifications of removing it. I know that some things are kept for back-compat with plugins and themes that still call the old media modal.
Also, please don't change the ticket summary like that. Think of it as the title of the ticket.
I'd like to start a dialogue about this issue as it has plagued me for years. I'm sick of telling people that our theme or plugin has a compatibility problem with a plugin simply because the conflicting plugin enqueues media-upload on every admin page.
The core issue is that any page that has media-upload enqueued on it will cause every Thickbox on that page to be modified to work as the media uploader expects the Thickbox to be modified, even if nothing on the page uses the media uploader.
There are three critical issues that need to be resolved in order to fix this problem:
There are many possible solutions to this issue, but given that I'm very confused on why the script does certain things (such as why it changes all the width and height arguments), I figured it would be better to start a discussion to decide what a new approach would require.
I'd like to propose two possible solutions.
The first one is relatively-simple and is more of a fix than a solution. The core issue seems to be that it is difficult to recognize specific Thickboxes from the main page looking into the Thickbox. Thus, the code simply targets everything. I suggest reversing the way this is structured.
Rather than housing the resize code outside of the Thickbox and modifying all of them, the resize code could be loaded by the wp-admin/media-upload.php page (the page loaded by the iFrame inside the media uploader's Thickbox) and use outward-looking checks to discover information about the window size. This will cause the code to be reliably run only on media uploader Thickboxes and removes any possible interference with other uses of Thickboxes (even if other non-media uploader Thickboxes exist on the same page).
My biggest concern with this type of approach is that it isn't really elegant. If WordPress core needs a solution to finely control how Thickboxes size and auto-resize themselves, it stands to reason that other code probably has need to do this as well.
My second suggestion is to improve the Thickbox code to handle a more robust set of query arguments. For example a link such as the following would emulate the current behavior of the the media-upload resize code.
There would be four attributes that would be the main focus:
All of the calculations will naturally also handle compensating sizes for necessary margin and padding sizes as well as compensating for the presence of the admin bar.
The code will also automatically handle resize events to ensure 1) that the current attribute options are respected and 2) that the Thickbox doesn't overflow the window.
With a setup like this, Thickboxes become much more useful to the average developer and an annoying code conflict source is removed.
Thoughts?