Closed petecooper closed 11 months ago
See, I kinda like this and have thought about it before. The only thing is that, despite caveat emptor, it's not just the server/disk that'll redline but Apache and PHP will have a heart attack. Namely the script execution time and the available memory will likely get exhausted long before the first 500 images show up. And that's before the browser decides to give up trying to draw all the HTML. Either way, it's white screen of death time, or a very abrupt, unfriendly system messsge.
So I dunno. Let's canvas opinion, but I'm not sure if we can trap errors of this magnitude that might be caused by massive execution times. And leaving it to chance makes me a bit nervous.
it's not just the server/disk that'll redline but Apache and PHP will have a heart attack.
Yes, you're absolutely right. However…
memory_limit
. set_time_limit
, and max_execution_time
could be tweaked. Magento does big ops stuff like this, and they expressly say to increase memory_limit
. set_time_limit
, and max_execution_time
accordingly. A big server with big resources can afford to ratchet up the above stuff without redlining…important thing to consider is this won't be for everyone – advanced pref, opt-in, etc – but operators with larger sites (servers) will benefit.
I think it's worth investigating this practically with a big DO server for a day or three: a 16GB + 4 CPU dedicated droplet is currently ~$0.19 an hour, a 32GB + 8 CPU dedicated droplet is ~$0.38 an hour…so won't break the bank
Sure, happy to try it out. Main concern - especially on the Images panel - is that an N thousand row table with thumbnails is going to cripple the client browser, which won't necessarily have the benefit of tonnes of RAM and resources. And since the (JavaScript-powered) Check All checkbox will only become usable once the DOM is loaded, you might be waiting a while before the UI is even drawn. I know of Txp sites with upwards of 6K images.
Client slowdowns could be somewhat mitigated with some lazy loading and HTML size hinting, so if we're not doing that, now would be a good time to trial it if we're gonna play.
As an interim thing for testing, could we implement a URL-only approach instead of a pref + button? Presumably less to unpick if it's a horrific mess…
https://example.com/textpattern/index.php?event=image&step=image_change_pageby&qty=all
https://example.com/textpattern/index.php?event=image&step=image_change_pageby&qty=0
I agree with @Bloke, processing thousands of rows for display can be time-consuming, even if the hardware suits. Imagine counting articles/images/etc for each user, this makes a serious db query (unless we store these values in txp_users
table itself, à la comments_count
).
But the OP problem looks a bit different: select all for deletion or some other operation. This should be doable, say, via a checkbox along, say, the multi-widget block.
Btw, for testing purposes it should be possible to write a 3-line plugin to extend the image_ui > pageby_values callback and add, like, 99999 as an option on the end of the sizes array. Not pretty but it should work.
Here's the world's tiniest plugin for doing that:
register_callback('smd_all_pages', 'image_ui', 'pageby_values');
function smd_all_pages($evt, $stp, &$pages)
{
array_push($pages, 99999);
return $pages;
}
Closing, addressed by https://github.com/textpattern/textpattern/issues/1862#issuecomment-1454268784 - thanks @Bloke
Is your feature request related to a problem?
Nope. Perhaps a hint of efficient laziness. Deleting 2,000+ images in blocks of 96 wasn't a fun experience.
What is the feature?
Opt-in advanced pref to show 'All' as an option on page-by quantity, with an accompanying pophelp that there's a chance the operation might take some time and/or use considerable resources, so use with caution.
Like this:
If a substantial Textpattern site has an appropriately-sized server, it should be able to handle the database queries and hard drive input/output…clearly this is an exercise for the administrator, but exposing the option would be a useful enhancement. Caveat emptor, in this case.
We have an existing gTxt (
all
) that would fit the bill for the button text, other considerations would include an extra button on a theme layout…beyond that, I can't think of other cosmetic aspects that would be affected.