Heavy Sql request loads

Thank you for giving the plugin a try and for taking the time to give this feedback. I am very sorry to hear there was heartache involved. I would welcome an opportunity to get more information and to address the performance issues you experienced.

There are only two times The Media Library Assistant (MLA) performs any database activity at all:

1. When you code an [mla_gallery] shortcode in a page or post.
2. When you access the “Assistant” submenu in the Media portion of the admin sceens.

If you are experiencing database issues at any other time, I’d like to know because that would be an unexpected problem.

The [mla_galley shortcode] uses the same database access routines (WP_Query) used by the WordPress [gallery] shortcode. If your issue is with [mla_gallery] I’d like to know more about the query you’re using so I can look into it.

The “Assistant” admin submenu is very similar to the standard WordPress Media Library display with one critital difference. The “where-used” reporting columns (Featured in, Inserted in, Gallery in and MLA Gallery in) need to look through every post and page in the site to do their job. The Gallery in and MLA Gallery in functions actually execute each shortcode query to see which pages and posts are included in the gallery output. This is, indeed, database intensive. WordPress requires this processing to be performed even if the where-used columns are hidden.

Because I have been concerned about this, I put a question in the “FAQ” section of the plugin page: “The Media Library Assistant table listing seems sluggish; is there anything I can do to make it faster?” Yours in the first response I’ve had.

There are many things I can do to reduce the database load required to perform the where-used functions, if that is where your issue lies. I can cache the results and re-use them (not done yet because the results will change if you edit the gallery shortcodes or the attachments). I can provide a settings switch to turn the processing off entirely until you need it, or make refreshing the where-used information a “click here to update/refresh” function.

If your issue is in some other area, I’d like an opportunity to address whatever you’ve found to be a problem. You can respond in this topic or reach me directly from the FTJ “Contact Us” page:

https://fairtradejudaica.org/our-story/contact-us/

Donald Knuth once said “Premature optimization is the root of all evil (or at least most of it) in programming.” I’ve been focused on adding functions and building an audience, but I want to do whatever I can to make this usable for larger sites, too.

Thanks again for your feedback. I hope I can use it to make the plugin better for everyone.

David Lingren

Hi David,

I will log into the site and retract my post. After debugging, I found the problem…and it was really lame. I’m using the Types and Views Plugins…and have around 60 taxonomies with 400 children that I am using for the custom post types generated by types and views. About 20 of my pages were carrying the same slugs as the types taxonomies. It’s funny, because there had been no problem with this for over 3 months and the all of sudden I got zapped and started removing plugins.

After doing a database optimization and removing your plugin…the site functioned ok again for a couple days, and then once again I strated crashing the mysql. So, not your plugins fault. I apologize.

Thank you for checking with this update and with the good news. I am happy you’ve solved your problem and, of course, pleased that my plugin was less involved than I’d feared.

Your post inspired me to finish up some database work I’d been pondering for a while now. The next plugin release will cache some of the where-used information and will allow the user complete control over which types of where-used reporting they want and how it is handled. Progress!

Thanks again for updating this topic and for using the Media Libray Assistant.

I have just released version 1.00, which contains enhancements to the “where-used” reporting that requires a lot of SQL processing.

There are four where-used reporting categories; Featured In, Inserted In, Gallery In and MLA Gallery In. Any of the four categories can be disabled if performance is an issue and the information is not immediately useful.

The Gallery In and MLA Gallery In categories require the most SQL processing. By default, they are now run once and cached for ten minutes before updating again. You can set these categories to “Dynamic” if updating on each page load is required. The cache is also flushed when posts or pages are updated.