jonhuck

@derwentx – nice – good to know we can stop the process once batched ??

We are having the same issue with clients on our hosting servers. Non-stop /wp-admin/admin-ajax.php?action=wp_1_wc_regenerate_images&nonce=d9e36adeef wasting a ton of RAM and CPU usage.

Example: 1 User with high LVE allocations of 8GB RAM 4xCPU 50 EP running 5.6 PHP-FPM with 10 second process idle timeout:

Result: 2GB RAM used in 5 WC simultaneous resizing process using about 1.5-2 CPU when no traffic on site. Their site is plugin heavy with around a thousand images – so it’s not typical – but still enough to raise alarms for unusal usage pattern.

The add_filter( ‘woocommerce_background_image_regeneration’, ‘__return_false’ ); in theme functions.php did absolutely nothing to stop the auto regenerate process once it had started – WC resizing processes ran for 4+ hours chewing up 1.5-2 CPU and 2GB ram the WHOLE TIME – this was during peak usage time for a shared server.

Their web Master tried using WP Control to check the WP Cron – if the regenerate cron was deleted it auto added itself again.

Can we get a fix to disable this “feature” – maybe this should be set to OFF as default and be MANUALLY TRIGGERED as an admin header alert option to run it after image size change / theme change detected.

Is there something we can use as server admins to stop this auto generate once it kicks in?

Looking at early impacts this auto generate has potential to cause major issues for both hosts / webmasters and reputation of WCommerce once a lot of users upgrade to the 3.3.x branch. Especially those with tons of images in their media library.

Another quick 3.3.2 roll out with fix to disable and give WC team option to rethink this forced “feature”…?

It won’t be long until others start complaining / realising WC is DOSing their own sites… hope this helps. ??

Sure – I understand PHP / WordPress pretty well – though don’t write many plugins or manipulate WP default admin tables very much.

AJAX would be the best way – though setting location to the plain View All Sheets url without action=copy AFTER the copy action was performed should to the trick. It’s a double page load but would take care of the problem.

I hear what you are saying about “not worth my time” as I’m always spending 1-2+ hours fixing someone elses coding problem and not getting paid for it. ??

Really good job for a free plugin – kudos and thanks.

Ok – so maybe looking at removing the action=copy from the completed copy page URL would do the trick? I wish I had more time to work on this / help = but I have to launch this site Monday (one of those projects ?? so am in the data entry stage – will definitely do the extra click workaround for now and later on take a closer look at the code and post back if I can find solution / help out.

I think it is actually a bug.

After I copy the Sheet I need to find the sheet to edit it – so I was sorting the columns to find it (as there is no search etc)

So if I click any action that causes that page to refresh e.g. click any column sort link the action=copy is re-executed. (the action=copy is in the sort url)

Even if I click the Pagination it executes the copy again. (the action=copy is in the pagination url)

A filter to remove the action=copy from Column sort links and Pagination links will fix this ??

Aaah – ok – that explains it. Thank you. Was wondering why All-Import couldn’t find the post type it to import data ??

Great work on this plugin so far. Will post this in Feature requests as think searching for a Sheet would be really important for my client and other users.

The answer was at top of Google on search for: default content worpress new custom post. Add to your functions.php

add_filter( 'default_content', 'my_editor_content', 10, 2 );

function my_editor_content( $content, $post ) {

    switch( $post->post_type ) {
        case 'sources':
            $content = 'your content';
        break;
        case 'stories':
            $content = 'your content';
        break;
        case 'pictures':
            $content = 'your content';
        break;
        default:
            $content = 'your default content';
        break;
    }

    return $content;
}

That code example has default content for 3 custom post types and the default for all new posts.

Simply replace the case ‘sources’ with the Post Type Slug of your custom post e.g. case ‘my_custom_post_slug’ and update the default content… add/remove any un-needed post types.

closed

List does show when a post is set to draft… just sorting is something client wanted – but it probably not necessary as there are the “status links” at top… Will look into a custom field as you suggest if can’t convince them it’s not needed ?? Was hoping it was something that someone had come across or had function / setting in CTP UI. Thanks for your time and suggestion. Appreciated.

I just came across a client wp site that was hacked in a similar way. The .htaccess file was modified to redirect any incoming traffic from search engines to another site…

I checked and the date of modification matched the date of 2 plugin files… the hello.php plugin was modified and a new file – probably the hackers file as it’s gzipped code wrapped in php – anuka.php was added…

Searching anuka.php on Google gave a few other sites’ open directories – all WP sites with anuka.php put in various plugin places… though no explanation of what it actually is… this seems to be something recent as Googled file dates for anuka.php start about 2 months ago.