Forum Replies Created

Viewing 15 replies - 76 through 90 (of 123 total)
  • Thread Starter Biranit

    (@biranit)

    No, it is definitely working and up to date. Why do you think it’s broken? What is the problem you run into?

    Thread Starter Biranit

    (@biranit)

    There is a “follow up” plugin for this one, that works on 3.5+ and continues to be maintained and updated:

    Scissors and Watermark
    https://www.ads-software.com/extend/plugins/scissors-watermark/

    Thread Starter Biranit

    (@biranit)

    Many thanks, Daniel. Much appreciated ??

    Hi Donncha,

    I just wanted to say I am really happy with the latest version. So far, everything – including preload (and we have 14,000 posts so far) – has gone smoothly, and it seems various bugs have been fixed. So many thanks for a great job done.

    I would like to make a suggestion, however, perhaps for future versions.

    Add a few options for what happens when a post is published:

    When a post is published:

    – Check box to clear homepage chace
    – Check box to clear author page cache
    – Check box to clear related (and only related) taxonomy (category/tags/custom taxonomy) cache

    I already added functions to my functions.php that do this on save_post, but I reckon this is important – especially for folks like me who use preload.

    Many thanks again,

    Bira

    Thuesen, just to be clear: I am not advocating you comment out these two lines. I have modified the plugin to a point where I do not know whether or not commenting out these two lines will be enough for you. This is an issue the developer needs to fix, as it is certainly a bug. What I CAN tell you, though, is that these two lines do NOT affect the core functionality of the plugin.

    It affects the dashboard with Plulz news that the plugin adds – so not the actual core functionality of the plugin.

    The dashboard news is self marketing for the plugin author, which I completely understand and is perhaps relevant to admins who install plugins – but is entirely irrelevant to the editors and authors. I already commented it out of the plugin (and posted a while ago about).
    I do not want the website’s editors to have that box – along with updates they actually need for their work – on their dashboard. We’re a news website, and this is not relevant to them.

    FYI, the problem lies in PlulzAdminClass.php – it enqueues these scripts:

    wp_enqueue_script( ‘dashboard’ );
    wp_enqueue_script( ‘postbox’ );

    One or both of these is causing the conflict with WordPress’s native behavior.

    I commented out both these, and it solved the problem (although I also commented out various other bits – eg the lanuage attributes, which should not be added to the admin area, etc).

    I have the same problem with the “Delete” link on the plugins page (works only if you right-click the link and open in new tab).

    Something in the SEO Facebook Comment plugin is interfering with the admin side of things?

    Hi Donncha,

    I would like to reiterate and add to FolioVision’s post. Your plugin was to me one of the best WordPress plugins – I’ve recommended it to every WordPress-based website I’ve worked with, and installed it myself in dozens of websites I’ve been involved with, small or big.

    I now find myself having to write various functions to overcome a host of issues – not all yet solved for me – since upgrading the plugin. Preload is extremely buggy – I don’t understand why, but it continues to delete itself and rebuild (even though that option is disabled), sending me dozens of error emails. Garbage collection most certainly does not work as it did – I wrote functions to sort out the issues it caused. And I am seriously shaking with fear in the thought of upgrading the next time there’s a new version, because the impact of WPSC not working on a website with 1 million pageviews a day and over 10,000 articles can be detrimental.

    I remind myself all the time that this is a free plugin. Though I will pay for it if it were not. But I urge you, as Alec stated, to keep it working and keep it working out of the box. Please don’t stray from its original simplicity and beauty.

    Many thanks,

    Bira

    Hi Donncha,

    I turned on debug for all IPs and clicked on run preload now. I don’t see anything in the debug file about preload – and also pages that I access (anonymously, from a different browser) don’t seem to show up in the debug.

    However, something very typical for category and tag pages is that it says for all of them something like this:

    10:14:59 /topic/us-troops-in-afghanistan/ No wp-cache file exists. Must generate a new one.
    10:14:59 /topic/us-troops-in-afghanistan/ In WP Cache Phase 2
    10:14:59 /topic/us-troops-in-afghanistan/ Setting up WordPress actions
    10:14:59 /topic/us-troops-in-afghanistan/ Created output buffer
    13:15:00 /topic/us-troops-in-afghanistan/ Output buffer callback
    13:15:00 /topic/us-troops-in-afghanistan/ Anonymous user detected. Only creating Supercache file.
    13:15:00 /topic/us-troops-in-afghanistan/ Gzipping buffer.
    13:15:00 /topic/us-troops-in-afghanistan/ Writing non-gzipped buffer to supercache file.
    13:15:00 /topic/us-troops-in-afghanistan/ Writing gzipped buffer to supercache file.
    13:15:00 /topic/us-troops-in-afghanistan/ Renamed temp supercache file to /home/toi/public_html/timesofisrael.com/wp-content/cache/supercache/www.timesofisrael.com/topic/us-troops-in-afghanistan/index.html
    13:15:00 /topic/us-troops-in-afghanistan/ Renamed temp supercache gz file to /home/toi/public_html/timesofisrael.com/wp-content/cache/supercache/www.timesofisrael.com/topic/us-troops-in-afghanistan/index.html.gz
    13:15:00 /topic/us-troops-in-afghanistan/ Writing gzip content headers. Sending buffer to browser
    13:15:00 /topic/us-troops-in-afghanistan/ wp_cache_shutdown_callback: collecting meta data.
    13:15:00 /topic/us-troops-in-afghanistan/ Did not write meta file: wp-cache-64883f325d9610a57494746fd1a6e21b.meta *1* *0* *1*

    This, despite the fact that the file DOES exist, and despite the fact that it keeps serving an old cached file. There is no error in the file path listed above.

    Does this help in any way?

    Thanks,

    Bira

    Well preload only ran once, Donncha. Or, to be precise, it ran over something like 10 days before everything was cached. And I don’t know if it’s running now except when a new post is added?

    Right now, this is the state of our Cache Contents (just refreshed):

    WP-Cache (1.28MB)

    35 Cached Pages
    18 Expired Pages

    WP-Super-Cache (1,095.79MB)

    12160 Cached Pages
    0 Expired Pages

    The cached pages number increases daily, of course.

    As for comments: we use the Facebook comments plugin so I don’t know.

    I added a function to sort out the categories issue to my functions.php – as things became rather urgent. My function is:

    function rgbtoi_prune_category_cache($post_id) {
    	if ( $post_id == null || empty($_POST) )
    		return;
    
    	if ( !isset( $_POST['post_type'] ) || $_POST['post_type']!='post' )
    		return; 
    
    	//verify post is not a revision
    	if ( !wp_is_post_revision( $post_id ) ) {
    		if (in_category(3, $post_id)) {
    			prune_super_cache( get_supercache_dir() . '/israel-and-the-region/', true );
    		}
    		if (in_category(4, $post_id)) {
    			prune_super_cache( get_supercache_dir() . '/jewish-times/', true );
    		}
    		if (in_category(5, $post_id)) {
    			prune_super_cache( get_supercache_dir() . '/israel-inside/', true );
    		}
    		if (in_category(6, $post_id)) {
    			prune_super_cache( get_supercache_dir() . '/ops-and-blogs/', true );
    		}
    		if (in_category(7, $post_id)) {
    			prune_super_cache( get_supercache_dir() . '/start-up-israel/', true );
    		}
    	}
    }
    add_action('save_post', 'rgbtoi_prune_category_cache', 15 );

    It’s not ideal, but at least it solves my immediate problem with regards to categories – which was the most urgent issue.

    I will remove it over night when there is little traffic (we got a few breaking news stories with heavy traffic at the moment) and will run debugging to let you know what it says.

    Thank you very much for your assistance – I do appreciate it.

    Hi Donncha, FolioVision,

    I am pretty sure there is a bug or a misconceived issue here. And I will try to explain myself better:

    1) I have ‘preload’ turned on for all posts. I do NOT have preload on for categories, tags, etc.

    2) I have garbage collection set to run every hour (3600 seconds) with timeout for files set to 600 seconds. It DOES state “next garbage collection <time>” on that page. However, it also states:

    “Warning! PRELOAD MODE activated. Supercache files will not be deleted regardless of age.”

    3) So category or tag pages have now been older than one week – and I see absolutely no method or way to make them refresh for visitors. It is a major issue for us.

    So the way I see it, despite NOT having preload set for categories and other taxonomies, garbage collection actually does nothing because preload is turned on for everything else. And, also, there is just never ever a method by which pages are refreshed. Despite having “Cache rebuild. Serve a supercache file to anonymous users while a new file is being generated” checked – it just never does anything to refresh these pages.

    The only pages that are fresh are posts, which get rebuilt when they are published or updated; and pages (such as the homepage) where I manually added prune_super_cache() to their update function…

    I should point out all this began since the latest upgrade, a couple of weeks ago.

    Thanks,

    Bira

    I have this issue with pretty much all major pages – categories, tags, author, etc. Anonymous users get served a week old page.

    I have the option for “cache rebuild” (serves anonymous users a cached page while building a new one) checked. It does not happen.

    For the homepage, I actually added a function to clear its cache whenever it is updated. I couldn’t allow it to remain cached.

    I am now thinking that I will have no alternative but to write a function that clears out the cached file for every category/tag/author/taxonomy of a post when it is published/updated, which is quite cumbersome.

    But I have no idea how to solve this another way, and it is a rather acute problem.

    I would appreciate getting some guidance here.

    Thanks ??

    Bira

    Thread Starter Biranit

    (@biranit)

    Done, thanks ??

    Thread Starter Biranit

    (@biranit)

    Sorry to continue with this one, but I think something is just really wrong.

    As mentioned, I changed the settings to preload less posts. And, by the way, I have “Refresh preloaded cache files every 0 minutes” (so disabled).

    Despite this, every day (I don’t know how often), the whole thing gets deleted and preloaded again – and because we have so many posts, it never actually manages to go through the whole thing! The most cached files I’ve seen it reach is around 7000. Right now, it’s got 4800 cached file and preload is still running (with the preload stalled emails being fired off once or twice or more a day).

    For whatever reason, it resets the number of posts back to “all” and ignores the 0 minutes…

    I just don’t know what to do. Up until 10 days ago, it all worked flawlessly.

Viewing 15 replies - 76 through 90 (of 123 total)