kuprosa

Honestly, I’ve never worked directly with the database and wouldn’t really be comfortable modifying the queries for fear of breaking the functionality or causing some otherwise unknown side-effect; I was just hoping to provide you some more insight on what maybe causing this (clearly long-standing) issue with your otherwise flawless (as I can tell) plugin ??

I came by all those other error reports just while Googling for a hopeful solution; the WHERE idea came from the first FAQ here: https://www.techonthenet.com/sql/insert.php

…No wait, that wouldn’t be it. But what about just adding a WHERE to the insertion, i.e. something like:

INSERT INTO wp_useronline (blahblah) VALUES (blahblah) WHERE not exists (SELECT * from wp_useronline WHERE user_ip = %s AND timestamp = CURRENT_TIMESTAMP AND user_type = $user_type);

Seems like that should *always* prevent such a duplicate entry, should it not?

Actually, perhaps this is overly obvious, but is that “Purge table” deletion immediately before the insert clearing previous records for the same user, so the new record can be inserted? If so, wouldn’t the solution just be something like changing:

OR timestamp < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL %d SECOND)

to

OR timestamp <= DATE_SUB(CURRENT_TIMESTAMP, INTERVAL %d SECOND)

so that if there’s already a record of the current user at the SAME moment (or earlier) it’ll be deleted?

Any information I could provide from my setup that might help? I did delve into the code a bit (obviously it’s coming from core.php, line 155 in v1.81), but was not able to figure out much…

It seems as though this problem has existed for more than four and a half years:

https://www.ads-software.com/support/topic/plugin-wp-useronline-plugin-28-wp301-broken

And was reported a year ago:

https://www.ads-software.com/support/topic/plugin-wp-useronline-wp-useronline-developing-error-messages

By a few different users:

https://www.ads-software.com/support/topic/plugin-wp-useronline-plugin-28-wp301-broken

…Would be very nice to get this fixed up, as I find myself deleting error_logs virtually every time I ftp into my server ??

Excellent find – and thanks for the fix! Will submit in an update shortly.

(For future reference though, please post support inquiries/messages on the plugin’s actual support page – I only check this forum periodically, it just so happened that I checked RIGHT after you posted this ;))

I’m not modifying/messing with/bug-fixing the plugin myself, just reporting the issue to the author(s) ??

>>I know this is not the support site, but couldn’t find https://www.justin-klein.com/projects/wp-fb-autoconnect anyplace to post this..

…Did you really read the page? There’s a link to “Feedback & Support” right at the top, as well as an entire section at the bottom. 1,573 messages so far, it couldn’t be *that* hidden…

>>Firefox 4.0 to 4.01 update also broke 1.9.2 version of this plugin. ??

Even if you couldn’t find the support page, this thread is “Does not work in IE9” (FF 4.01 is not IE9, please stay on topic).

…But in any case, I’m currently using FF 4.0.1 and it works fine. Please try it on another computer.

Lol, no idea – or I already woulda fixed it & submitted a patch ??

They always get published on my site, just not on Facebook (unless page caching is off…)

I know it’s weird, but believe me – I spent the better part of an hour changing EVERY setting, scheduling posts for 2min later, etc.

Alright, so I’ve gone through and tried each of w3-total-cache’s caching options one at a time; the one that breaks Wordbooker’s ability to push Scheduled posts to Facebook is the “Page Cache.” Object Cache, Database Cache, Minify, and Browser Cache all work fine – but as soon as Page Cache is enabled, Wordbooker stops pushing scheduled posts to Facebook.

Replied in detail via email

Steve: Back on topic for this thread, I’ve tested several more scheduled posts, both with w3totalcache on and off. It seems that with w3totalcache off, scheduled posts work 100%. With it on, they work *sometimes*, and other times they don’t get pushed to Facebook – presumably having to do with the current state of the cache. Might be something for you to explore with Frederick Townes, the w3totalcache author, when you have a moment…

Haha, that’s exactly what I did ?? I capture output from get_header to wp_head, and did add an option to disable this. While I am aware that it isn’t a “clean” solution per se, the way I see it, it’ll make the plugin work on all browsers without people needing to intervene – and if it causes any problems they can always turn it off, or I can always get rid of it if it becomes really problematic (though I don’t see how it would). This is actually exactly how the major cacheing plugins insert minification includes anyway – and will enable things to “just work” out of the box, far better than hassling people with warnings and instructing them to fix them on their own IMO.

Nm, figured it out – v1.9.2 should work with IE9 out-of-the-box! ??