Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Same here too. 5 client sites currently showing the piracy message. The plugin was also blocking login to the admin areas until I fixed them by using similar methods to those mentioned above. The plugin is still automatically disabled by the developer and the sites are being plagued by spam again.

    The WordPress debug logs on these sites have filled with tens of thousands of PHP warnings about undefined variables since version 1.9.42 was automatically installed by the Envato market plugin. I tracked down the bug in the code and contacted him on Twitter to show him the problem, and his response was to block me.

    When the developer was contacted and asked for a refund, he wrote back, saying the refund request was fraudulent.

    I’ve also got a screen grab of a support message posted yesterday on Codecanyon posted by someone with the same problem, but today this message is hidden and saying “This comment is currently being reviewed”. along with many other recent messages which I can only assume are about the same issue.

    It’s a shame, as when the plugin is working properly, it does its job well. Unfortunately, the developer’s customer service attitude is aggressive and reprehensible & we will be removing the plugin from our clients’ sites and looking for an alternative, even if he does end up fixing these problems.

    Unfortunately, this change has broken the custom spinner in all the previous sites I have built for clients. Would it be possible to reinstate the ability to change the spinner via the filter in functions.php, and just add the css customisation as an additional method, instead of replacing it?

    I’ve been getting the same on one of the sites I manage – it uses both Simple History and iThemes Security Pro too.

    There are hundreds of ‘Logged out’ messages attributed to user ‘Other’, but each one seems to be twinned with a corresponding ‘Failed to login to account with username “xxx” because an incorrect password was entered’ message – both referencing the same IP address.

    e.g.:

    id 194
    logger SimpleUserLogger
    level warning
    date 2015-06-13 10:37:49
    message Failed to login to account with username “{login_user_login}” because an incorrect password was entered
    type
    initiator web_user
    context_message_key user_login_failed
    _user_id
    _user_login
    _user_email
    login_user_id 4
    login_user_email [email protected]
    login_user_login xxx
    server_http_user_agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36
    _message_key user_login_failed
    _server_remote_addr 62.210.105.116
    _server_http_referer https://xxx.co.uk/wp-login.php

    ================

    id 195
    logger SimpleUserLogger
    level info
    date 2015-06-13 10:37:49
    message Logged out
    type
    initiator other
    context_message_key user_logged_out
    _message_key user_logged_out
    _server_remote_addr 62.210.105.116
    _server_http_referer https://xxx.uk/wp-login.php

    ==================

    I was a bit freaked out at first, as I thought the site had been compromised somehow, but after checking the site for suspicious changes & looking through the iThemes Security log, it looks like these entries all correspond to brute force attempts that have been locked out automatically by iThemes Security.

    I’m happy to ignore these messages as being spurious, but it would be nice for them not to appear at all, as it’s easy to miss genuine issues amongst all this background noise. Would this be something that iThemes would have to address, or can changes be made to Simple History to solve this?

    Cheers,
    Mathew

    Thread Starter tay23

    (@tay23)

    Hi Jason.

    I was previously using 1.5.4, but I’ve just updated to v1.5.5 and the errors have now stopped. Many thanks for sorting this out so quickly!

    Cheers,
    Mathew

    Same here. Avoid this version of the plugin!

    I’ve been having exactly the same problem myself – when using [raw]…[/raw] as the tags.

    However, I’ve just tried using <!–raw–>…<!–/raw–> instead, and it’s fixed the problem!

    Try giving that a go & see if it works for you.

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