Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Sure – you could do that.

    Upload the DB (make backups of everything), and then visit the wp-admin. You’ll be prompted to ‘upgrade’ the database.

    That said – I’m not sure if taking the drastic route of moving servers is needed here…

    Either way you need to ensure you have a ‘fresh’ install of WordPress on your server, all your plugins are up to date, and you’ve identified how they managed to gain access the first time round.

    If you don’t have a fresh install – and you’re copying files from the old server to the new – you have to be 100% sure that you can account for every file you’re copying, and that the contents of the file matches exactly as it should. Otherwise you could be copying over files placed/modified by the hacker.

    Take a look at this article:
    http://codex.wordpress.org/FAQ_My_site_was_hacked

    @josh are these network of sites on the same IP range / subnet? That would be my best guess. And you’re very welcome, no problem at all.

    @esmi patch in ticket changes force_feed error to something more general as per 21017#comment:3

    As for force_feed() … still reluctant, it’s really meant as a way of accepting feeds with the wrong mime type, and not a way to handle broken, incorrect or incomplete feeds, which should fail by design.

    http://simplepie.org/wiki/reference/simplepie/force_feed

    I think we will have to agree to disagree on this part! 😉 Thanks for your help though!

    Josh’s continuous fail was definitely down to a Google limitation put down on his server IP, the CURL request confirms this.

    As for the general / intermittent issues seen by other users, I agree fully the feed can be temperamental. Spent some time investigating alternative feeds, but have a feeling we’re stuck with this (without requiring users to have an API key). Arguably force feed could fix this, but it could also break things further when a feed actually is broken.

    If the feed is invalid, let SimplePie catch it, and inform the user in a nice error message – otherwise, load ’em up.

    Either way, if a feed is invalid it’s up to the feed provider to fix, and not an adaptation we should make to core, imho.

    @esmi: Fair assumption, sorry my apologies for not explaining clearly.

    Although they were valid for us (checking from our own IPs/server IPs), the response Josh’s server received was a HTML document containing a warning, (as his server IP was triggering the Google Captcha) rather than a valid RSS feed.

    So in effect, SimplePie was correct in it’s warning that the feed was invalid. We just need to handle this better for use-cases where it always fails. 🙂

    Google IP ban support link for reference. Might be worth filling that in, and hoping they take a look.

    A possible work around in your case might be (other than waiting for Google/changing the server IP):

    1. Sign up here: https://code.google.com/apis/console
    2. Request access to the Google Custom Search API
    3. Get your API key from the API Access Menu
    4. Use the link below in WP, remembering to put in your API key & domain name.
    5. https://www.googleapis.com/customsearch/v1?key=INSERT-YOUR-KEY&cx=017576662512468239146:omuauf_lfve&alt=atom&q=link:http://joshlobe.com/

    Beware: The standard RSS feed from Google uses Google Blog Search to return only blog results. This feed uses standard Google Search, so returns all sites linking to your blog.

    Without diving into the docs don’t know if it’s possible to filter this further I’m afraid, but do let me know if you find a way! 🙂

    Interestingly, running this locally on my Windows machine throws an SSL cert errors. Try this advice if you see that: http://code.google.com/p/google-api-php-client/issues/detail?id=22

    Finally – it will be worth running a check of all websites running on your servers IP, to make sure there is no malware/unwanted PHP code lying around hitting Google’s servers. Server logs can help a lot with this if setup correctly and your server – otherwise any good host should be willing to help.

    Esmi – thanks for passing on my comments 🙂

    Josh – wanted to reply to your specific issue in here rather than the ticket.

    As mentioned, be careful with force_feed, as if a feed is failing it is usually failing for a reason … as you discovered above. (Sorry but for this reason the patch I submitted in the ticket doesn’t enable force_feed here).

    Your theory regarding the server IP and Google’s CAPTCHA ring true – previously I’ve only seen this error intermittently and put it down as temporary Google/network issues.

    Did you happen to notice the HTTP status code returned in the CURL response header? I can’t reproduce at the moment – the full send/response including headers would be perfect if at all possible.

    Looking to add some better error checking to the widget as part of this patch.

Viewing 6 replies - 1 through 6 (of 6 total)