I've discovered an issue involving attachment.php which likely impacts most image-centric sites:
* Please bear in mind that I'm not a programmer -- the essence of what I'm saying appears to be correct but my theory/explanation might be somewhat inaccurate
I rely heavily on thumbnails (an average thread page on my site contains around 50) -- the image source for thumbnails runs attachment.php (src="attachment.php?thumbnail=100320").
Once a thread loads, attachment.php is executed for every single thumbnail and pulls the proper AID from a string (PID-based) generated in showthread.php. In other words, MyBB pulls thumbnail images through an intermediate script. As you can imagine, when attachment.php is loaded 50 times by ONE user in response to loading one page (on a forum with around 100 guests and members browsing around) the whole thing bogs down. I understand the intent (my guess is to conceal actual files names) but it's a huge waste of resources.
Does anyone know of a concrete way of modifying showthread.php to simply echo the path, name and format of thumbnail images (which are stored in uploads) and link them to the appropriate attachment ID inside a post? Under this configuration, only after clicking a thumbnail would attachment.php run -- the browser would pull thumbnail images directly. The downside is the location and names of image files would be visible.
Alternatively, maybe there's a way of handling thumbnails with a separate script that's called once per post (one time for multiple thumbnails).
This seems to be the reason my site runs like crap.
attachment.php is used to check permissions to view attachments.
(2015-04-17, 09:53 PM)laie_techie Wrote: [ -> ]attachment.php is used to check permissions to view attachments.
Understood, which is why I'd prefer that attachment.php only run when attachments are actually opened, not when thumbnails are displayed. Each thumbnail has an image source of the following nature:
scr="attachment.php?thumbnail=x"
This results in attachment.php being run 10s of times per page per user when viewing attachment thumbnails. My forum is configured to allow guests and members to view thumbnails with members having access to full attachments.
I was wrong about attachment.php -- both showthread and attachment query the attachment table.
Showthread.php does this:
// Get the attachments for this post.
$query = $db->simple_select("attachments", "*", "pid=".$mybb->input['pid']);
while($attachment = $db->fetch_array($query))
{
$attachcache[$attachment['pid']][$attachment['aid']] = $attachment;
}
Attachment.php handles multiple functions, including the display of thumbnails. I don't care about permissions for thumbnails. Is there a straightforward way to avoid having each thumbnail run attachment.php to locate an image source? Ideally, one query would be performed per page or post.
Attachment.php:
if($mybb->input['thumbnail'])
{
$aid = intval($mybb->input['thumbnail']);
}
else
{
$aid = intval($mybb->input['aid']);
}
if($mybb->input['thumbnail'])
{
$ext = get_extension($attachment['thumbnail']);
Each thumbnail runs attachment.php and queries the attachment table -- tens of times per page per user and around one hundred users are on the site at a given time -- this is not efficient.
@SteelCurtain experienced the same issue:
http://community.mybb.com/thread-164841.html
Is there a simple way to pull thumbnail images directly from the uploads folder (raw paths and files) based on $attachment generated in showthread.php -- linking those thumbnails to the appropriate attachment ID -- rather than pulling thumbnails through attachment.php?
(2015-04-17, 11:22 PM)mrdeltoid Wrote: [ -> ]Each thumbnail runs attachment.php and queries the attachment table -- tens of times per page per user and around one hundred users are on the site at a given time -- this is not efficient.
I can confirm this issue - each thumbnail requires at least 1 attachments table query (and probably also these 2:
https://github.com/mybb/mybb/blob/featur...php#L61-62 EDIT: yep, they seem to be executed for each thumbnail, cache doesn't work due to separate calls). Which is inefficient with many thumbnails on one page.
Moving to bug reports, but I'm not sure if there's a way to optimise it that late in 1.8.x without breaking plugins.
We could probably add a setting which allows thumbnails to be directly included. Though I'm not sure whether we should really include it in the core. Probably the esieast way would be either a plugin hook in "get_post_attachments" or adding the full path to the "$attachments" array, afterwards it's a little template edit.
PS: you can already do what you want. Edit template "postbit_attachments_thumbnails_thumbnail" and change the image source to:
uploads/{$attachment['thumbnail']}
However you need to edit the uploads path as you can't use the setting here. So the change we could do in the core to get the absolute path.
Why doesn't it loads all attachments in showthread.php instead? Hide them or show them as links if no permission to view.
Any other opinion on this?
(2015-07-06, 08:27 AM)Omar G. Wrote: [ -> ]Why doesn't it loads all attachments in showthread.php instead?
Not sure. But it definitely would be much more optimal that way. However, changing this now may break some plugins since 2 hooks are ran when each attachment is loaded.
So I'd reject this, unless there's another way to optimise it without breaking plugin compatibility. And we should make it less resource-hungry in 2.0.
(2015-07-02, 07:54 AM)Jones H Wrote: [ -> ]We could probably add a setting which allows thumbnails to be directly included. Though I'm not sure whether we should really include it in the core. Probably the esieast way would be either a plugin hook in "get_post_attachments" or adding the full path to the "$attachments" array, afterwards it's a little template edit.
PS: you can already do what you want. Edit template "postbit_attachments_thumbnails_thumbnail" and change the image source to:
uploads/{$attachment['thumbnail']}
However you need to edit the uploads path as you can't use the setting here. So the change we could do in the core to get the absolute path.
Wow! I'm really happy to see my old post incorporated into development plans for 1.8/2. Your suggestion, simple as it is, fixed my forum. Thanks!
We don't need to remove how it works in 1.8, just to change how it works, but keeping the old one for compatibility issues.