Plugin Author
Aesqe
(@aesqe)
@dan.stefan: “main-form.php” is included only via ajax in the File Gallery metabox, which is displayed only on the post edit page.
How did you determine that this was “main-form.php”‘s fault?
Plugin Author
Aesqe
(@aesqe)
In case you meant the media listing page, then “file_gallery_media_custom_column” function found in “file-gallery.php” could be causing the problem, because it reads media tags for each attachment on the page. But unless you’re listing all 10k attachments on a single page, I don’t see how that would cause any server overload.
You can turn off displaying of media tags on the media listing page by going to media options and unchecking the “Display media tags for attachments in media library?” checkbox (section “Edit screens options”).
Actually the code for it is ran on the post listing pages too. You call the file_gallery_load action every time you call file_gallery.init(). Inside that action, you specifically call a require_once(‘main-form.php’). AFAIK the form is displayed only on the edit pages, however the ajax call is done on the admin post listings too since file-gallery.js is included on those pages.
I was a wrong above in saying it’s included on all pages, it’s just included on post listing/editing screens, but while running on the post listing pages it overloads the server with requests(in the case of large media libraries)
@Aesque’s second post: No that was not the case, nor the problem. It happened on the edit.php page inside the admin. This is a bug, I removed everything other plugin from the server and it still used 100% cpu for about 4-5 minutes(it was just a development server, but my production server has a lot more images).
Plugin Author
Aesqe
(@aesqe)
oh god… *facepalm*
I really appreciate these moments when I feel like a complete idiot 😐
@dan-stefan: thank you so much for pointing this out. File Gallery was initially present only on single post editing screens, but then I added a few features here and there which required some javascript, and, without much thinking (obviously), I included the whole File Gallery js file – without checking which page is currently active and what features are actually needed.
I’ll fix it as soon as I get home, thank you once again.
Great! I’m mostly glad it was not a conflict with other plugins, I was quite stumped to see such high cpu usages at first with no aparent reason(my first possible suspect was thumbnail regeneration, but that worked as expected).
Basically including the whole js file is no problem in my oppinion, as long as it doesn’t try to start something too big, anyways glad I could help. Maybe I get time further on and I can also help with this plugin since it’s quite awesome(great job btw).
Plugin Author
Aesqe
(@aesqe)
I’ve fixed this in v1.7.4.1, should be fine now. Please try it out when you can.
And thanks for the nice comments 🙂 If you have any further suggestions for improvement or patches, etc., please do post them here.
